Shift Left e Right: Redesenhando o SDLC Inteiro em Torno de Agentes

Domingo à noite eu costumo fazer uma coisa meio chata: reviso o que prometi no início da semana e comparo com o que de fato entregamos. Essa semana o exercício me incomodou. Adicionamos agentes em mais um ponto do pipeline, comemoramos o ganho de velocidade ali, e o time como um todo não sentiu diferença nenhuma no fim da sprint.

Não é a primeira vez que isso acontece, e suspeito que não é só comigo. A gente aponta o agente para a etapa de escrever código, ele escreve rápido, todo mundo aplaude o commit mais veloz, e a entrega continua no mesmo ritmo de sempre. O gargalo simplesmente se moveu para o próximo balcão da fila, que continua humano, manual e lento.

Esse é o fio que quero puxar hoje, fechando a semana com uma reflexão mais de fundo do que de notícia. A ideia de "shift left e right" andou circulando em discussões sobre desenvolvimento agêntico em 2026, e ela captura o erro que descrevi acima: tratar agente como aceleração pontual de uma etapa, em vez de redesenhar o ciclo de vida de desenvolvimento de software inteiro em torno deles. Vou explicar o que isso significa na prática, com exemplos de cada estágio do SDLC tradicional.

---

O Erro De Colar IA Em Cima Do Workflow Antigo

O padrão que mais vejo em squads que adotam agentes é o mais intuitivo possível: pega o fluxo que já existia, requisito por humano, design por humano, código por humano, teste por humano, deploy aprovado por humano, e troca uma peça por vez. Primeiro trocam quem escreve o código. Depois, talvez, quem escreve o teste. O resto permanece intocado.

O problema é que esse fluxo antigo foi desenhado para o ritmo humano em todas as etapas, com filas dimensionadas para a velocidade de uma pessoa pensando. Quando você acelera só uma estação dessa linha de produção, ela não fica mais rápida no total, ela só empurra fila para a estação vizinha. O indivíduo sente ganho, o sistema não sente nada, ou sente pior.

Organizações que tratam IA agêntica como uma camada de produtividade colada sobre o workflow existente relatam ganhos modestos, e isso não é coincidência. É consequência direta de mexer numa peça só e deixar o resto do encaixe do jeito que estava. O agente que escreve código dez vezes mais rápido não resolve nada se a aprovação de design ainda leva a mesma semana de antes, porque o código rápido só vai esperar na fila de quem ainda não decidiu o que construir.

Já as organizações que redesenham o ciclo de vida inteiro em torno da IA agêntica relatam ganhos muito mais significativos, e a diferença entre os dois grupos não é o tamanho do investimento em ferramenta. É a disposição de tocar em cada etapa, não só na mais óbvia de automatizar. Foi esse dado que me fez reler minhas próprias métricas de sprint com outros olhos.

---

Shift Left: Agente Entra Antes Do Código Existir

Shift left, nesse contexto, significa levar agente para as etapas que tradicionalmente vêm antes de qualquer linha de código: levantamento de requisito, design de solução, planejamento de sprint. É a parte do SDLC que a maioria dos times ainda trata como território exclusivamente humano.

Na prática eu já vi agente participando da etapa de requisito de um jeito concreto: pegar uma demanda vaga de produto, cruzar com o código existente e com tickets antigos, e devolver uma lista de perguntas de esclarecimento antes que o desenvolvedor perca tempo interpretando ambiguidade. Isso muda a reunião de refinamento, que deixa de ser "vamos entender o que foi pedido" e passa a ser "vamos validar o que o agente já entendeu".

Na etapa de design o ganho aparece de forma parecida: o agente gera duas ou três propostas de arquitetura compatíveis com os padrões que o time já usa, aponta trade-off de cada uma, e o humano decide entre opções concretas em vez de partir do zero. Isso não substitui o arquiteto, mas corta o tempo entre "temos um problema" e "temos um desenho para validar" de dias para horas.

E no planejamento, agentes já decompõem uma intenção de alto nível, "construa essa funcionalidade", em tarefas menores, estimam dependência entre elas e sinalizam risco antes que o time comece a codar. É essa decomposição automática que abre espaço para delegar intenção em vez de quebrar tarefa manualmente toda vez, e é esse tipo de orquestração entre etapas que a Forrester descreve ao falar da indústria saindo do assistente dentro do editor para o agente orquestrado cobrindo o SDLC inteiro.

---

Shift Right: Agente Entra Depois Do Código Pronto

Shift right é o espelho do shift left: levar agente para as etapas que vêm depois do código escrito, teste, revisão, deploy e operação em produção. É território que também fica de fora quando a conversa sobre IA agêntica se limita a "o agente escreve código melhor".

No teste, o exemplo mais direto é o agente que gera casos a partir do próprio diff, incluindo cenário de borda que um humano apressado deixaria passar, e já roda a suíte antes de abrir o pull request. Isso muda o papel do QA, que passa a revisar cobertura e qualidade dos testes gerados em vez de escrever cada caso manualmente.

Na revisão de código, agentes fazem uma primeira passada disciplinada, checando padrão de projeto, vulnerabilidade conhecida e convenção do time, antes que o revisor humano abra o pull request. O humano gasta o tempo dele julgando decisão de design e contexto de negócio, não caçando import esquecido. Isso reduz o tempo de review sem reduzir o rigor, o ponto que ficava escondido quando só a codificação acelerava.

No deploy e na operação, agentes monitoram métrica de produção logo depois do release, comparam com o comportamento esperado, e disparam rollback ou alerta antes que um humano perceba o problema no dashboard. Essa etapa historicamente ficava esquecida nas conversas sobre produtividade, porque acontece depois que o desenvolvedor já "terminou" a tarefa, mas é onde incidente de produção nasce.

O ponto comum entre shift left e shift right é expor o gargalo que estava escondido. Quando você acelera só a codificação, o gargalo migra silenciosamente para requisito, design, teste ou deploy sem que ninguém perceba de onde veio o atraso. Quando coloca agente em várias etapas ao mesmo tempo, o atraso que sobra fica visível, porque não há mais etapa lenta disfarçando as outras.

---

Por Que Medir Só A Escrita De Código Esconde O Ganho Real

Esse redesenho do SDLC muda o que uma métrica tradicional consegue te contar. Lead time e frequência de deploy, os pilares do DORA, mudam de significado quando o ciclo de vida inteiro é redesenhado, porque passam a capturar o efeito combinado de agentes em cinco ou seis etapas diferentes, não só o efeito de um agente escrevendo código mais rápido numa etapa isolada.

Já escrevi em /blogs/20260603_dora_metrics_ia_retrabalho_produtividade sobre como o DORA continua sendo uma âncora honesta, mas insuficiente sozinho, quando o assunto é medir o impacto real da IA no fluxo de trabalho, especialmente quando retrabalho entra na conta. Se você só olhar a velocidade de escrita, vai comemorar o número errado, exatamente como descrevi em /blogs/20260610_metricas_alem_dora_paradoxo_produtividade_ia, sobre métricas além do DORA e o paradoxo da produtividade com IA. O redesenho de SDLC agrava esse risco, porque agora tem mais etapas acelerando ao mesmo tempo, e mais lugares onde o ganho de uma etapa pode estar mascarando perda em outra.

A recomendação prática que tenho visto ganhar força em 2026 é pilotar agentes em múltiplos estágios do SDLC simultaneamente, e não numa etapa isolada, exatamente para forçar essa visibilidade cruzada. Não é sobre rodar mais experimento por rodar; é sobre garantir chance real de revelar onde o sistema ainda está lento, em vez de mostrar só a estação escolhida.

Se você vai redesenhar requisito, design, teste e deploy em torno de agente, precisa também redesenhar o que mede em cada etapa, não só continuar olhando commit e pull request como se nada tivesse mudado ao redor.

---

Como Começar O Redesenho Sem Quebrar O Time

Redesenhar o SDLC inteiro não significa jogar o processo atual no lixo numa sexta-feira e chegar diferente na segunda. Significa escolher, de forma deliberada, pelo menos uma etapa anterior ao código e uma posterior a ele para colocar agente ao lado do humano, além da codificação que já está coberta.

Uma forma segura de começar é escolher uma etapa de cada lado por sprint: na anterior, talvez o agente ajudando a decompor épico em tarefa menor; na posterior, talvez o agente gerando o primeiro conjunto de teste a partir do diff. Você não precisa reformar as seis etapas no mesmo mês, só garantir que pelo menos uma esteja de cada lado da escrita de código.

Outro ponto que aprendi observando meu próprio time: o redesenho só funciona se o humano souber exatamente qual decisão ainda é dele. Se o agente decompõe tarefa, mas quem prioriza continua sendo o tech lead, isso precisa estar explícito, e o mesmo vale para quem aprova cobertura mínima de teste. Ambiguidade sobre quem decide o quê é o jeito mais rápido de transformar redesenho promissor em confusão de responsabilidade.

E o terceiro ponto é medir a transição, não só o resultado final. Antes de redesenhar, registre onde as filas se acumulavam, review, teste, aprovação de design, e depois olhe se elas encolheram ou só se moveram para um lugar novo. É provável que o gargalo mude de endereço mais de uma vez antes do sistema encontrar equilíbrio, e isso é normal, não é fracasso do redesenho.

---

Conclusão

Fechando a semana, o que fica para mim é uma correção de expectativa mais do que uma descoberta espetacular. Agente não é peça que se encaixa numa etapa só do processo que já existia; é peça que muda a forma do processo inteiro, e o time que trata isso como camada em cima do workflow antigo vai continuar se perguntando por que o ganho individual não vira coletivo.

O que a Forrester chama de passagem do assistente de código para o agente orquestrado cobrindo o SDLC inteiro é, no fundo, uma mudança de mentalidade antes de ser uma mudança de ferramenta. Shift left e shift right não são slogans bonitos, são um convite para olhar as etapas que a gente historicamente ignorava, requisito, design, teste, deploy, operação, e perguntar onde o gargalo real está se escondendo agora.

Não tenho resposta fechada de como isso vai se acomodar no meu time nos próximos meses, e acho essa incerteza honesta. Mas sei que domingo que vem vou revisar de novo o que prometemos, e prefiro perguntar sobre o sistema inteiro do que só sobre a velocidade de quem escreveu o código.

Fontes:

• Forrester — Agentic Software Development Takes The Lead: From Code Assistants to Orchestrated SDLC Agents
• Interclypse — How Agentic AI Is Reshaping the Software Development Lifecycle
• Virtido — Agentic Workflow Patterns & Best Practices [2026]
• CIO — How Agentic AI Will Reshape Engineering Workflows in 2026