Times ágeis foram desenhados para um mundo em que escrever código era a parte cara do trabalho. Sprint de duas semanas, refinamento antes, review depois, estimativa em pontos: tudo girava em torno de proteger e prever o tempo de quem implementava. Adotar agilidade com I.A. não é rodar esse mesmo ciclo mais rápido, é aceitar que o gargalo mudou de lugar. Quando uma fatia vertical de funcionalidade sai de três dias para três horas, o que estrangula a entrega passa a ser a clareza do requisito, a aderência ao padrão da base e a confiança no que foi entregue. Nenhuma dessas três coisas melhora sozinha porque o time ganhou um assistente.
O gargalo saiu da implementação e foi para a verificação
Um desenvolvedor com assistência de I.A. bem orientada produz em uma tarde o que antes ocupava boa parte da sprint: endpoint, camada de aplicação, handler, migration, teste unitário, atualização de contrato. O efeito colateral é desconfortável e aparece rápido. A fila de trabalho refinado seca no meio da sprint, e o time descobre que nunca teve requisito suficiente, apenas tempo de implementação suficiente para esconder a falta. O refinamento sempre foi o processo mais frágil da maioria dos times, mas o custo dessa fragilidade ficava diluído nas semanas de codificação.
Depois vem o segundo efeito. Se o time consegue abrir cinco pull requests por dia e a capacidade de revisar continua sendo dois, a fila apenas se moveu para outro lugar. Trabalho parado esperando revisão é inventário, e inventário não vira receita. Para o negócio, o desperdício só troca de endereço: não se perde mais dinheiro esperando código, se perde construindo rápido a coisa errada ou empilhando entrega não validada.
Especificação frouxa não dá erro de compilação
Este é o ponto que separa quem tem ganho real de quem tem ganho aparente. Um modelo de linguagem preenche lacuna de requisito com o que é estatisticamente plausível, não com o que a regra de negócio exige. E o resultado compila, sobe e passa nos testes.
Considere uma tarefa comum: "permitir que o cliente cancele a assinatura com reembolso proporcional". Parece claro. Um assistente vai implementar a versão mais frequente nos exemplos que já viu: cancelamento imediato, reembolso pro-rata por dia corrido, sobre o valor cheio do plano. Nenhuma dessas escolhas foi decidida pela empresa. Ficaram de fora, sem que ninguém perceba, decisões que valem dinheiro real:
- o acesso encerra na hora ou no fim do ciclo já pago?
- o pro-rata é por dia, por ciclo de faturamento ou não existe abaixo de um valor mínimo?
- a base de cálculo é o valor cheio ou o valor efetivamente pago, com cupom e desconto aplicados?
- assinatura anual paga à vista devolve os meses restantes ou gera crédito?
- imposto retido volta para o cliente ou não?
- cancelamento durante inadimplência é permitido?
O código entregue vai responder todas essas perguntas, com ou sem você. Essa é a diferença entre requisito e especificação. Requisito é a frase; especificação é a frase com linguagem do domínio explícita, invariantes declaradas ("nenhum reembolso pode exceder o valor líquido recebido"), critérios de aceite em Given/When/Then que cobrem os casos ambíguos e escopo negativo por escrito ("não trata cancelamento de contrato corporativo nesta tarefa"). Em outras palavras, a ambiguidade que antes era resolvida numa conversa de corredor no meio da implementação, quando o desenvolvedor tropeçava nela, agora precisa estar resolvida antes.
Na prática isso significa que a Definition of Ready passa a pesar mais do que a Definition of Done, invertendo o instinto de quase todo time ágil.
Engenharia de contexto é a nova disciplina técnica
A qualidade do que sai do assistente é uma função direta do que entra. Sem contexto, ele não erra por incompetência, erra por generalidade: escolhe o padrão médio da internet em vez do padrão da sua base. Tarefa a tarefa, isso produz cinco jeitos diferentes de validar entrada, três estratégias de tratamento de erro e duas convenções de nomenclatura convivendo no mesmo repositório. É entropia arquitetural acumulando na velocidade nova.
O contraveneno é tratar o contexto como artefato mantido, não como prompt improvisado. Na prática: modelo de domínio e glossário escritos, decisões de arquitetura registradas com a razão por trás delas, convenções da base documentadas, e a indicação explícita de um trecho de código existente que o assistente deve usar como referência de estilo e estrutura. "Implemente seguindo o mesmo padrão do módulo de faturamento" vale mais do que meia página de instrução genérica sobre boas práticas.
Vale também limitar a fatia. Tarefas verticais e pequenas, com contrato de entrada e saída definido, produzem código muito melhor do que pedidos amplos. O assistente é excelente em atravessar as camadas de uma funcionalidade estreita e ruim em manter coerência em algo que toca dez arquivos e três domínios.
Revisão e Q.A. deixam de ser etapa final e viram contrapeso
Volume maior de código por sprint significa superfície maior de regressão por sprint. E existe um problema estrutural: quem escreveu, humano ou assistente, é o pior avaliador do próprio trabalho, porque já está convencido de que a solução é aquela. Quando o mesmo agente escreve a implementação e o teste, o teste tende a espelhar o comportamento implementado, inclusive o defeito. Cobertura alta com bug preservado é o pior dos mundos, porque compra confiança sem entregar garantia.
Isso muda duas coisas de forma concreta. O code review sai da sintaxe e vai para o que a máquina não avalia: aderência ao domínio, coerência com o padrão da casa, o que foi silenciosamente decidido no lugar do negócio. Já o Q.A. precisa ser independente e com contexto novo, projetando caso negativo e de borda a partir da especificação e não do código, exercitando o comportamento real do sistema, com build, lint e teste rodando de verdade e evidência anexada. Na mesma linha, versionamento disciplinado, feature flag e rollback confiável saem da caixa de "detalhe de infraestrutura" e passam a ser a condição que permite andar rápido sem medo.
Segurança é o custo esquecido da velocidade
Código gerado reproduz com fidelidade os padrões mais comuns que existem por aí, e alguns deles são vulnerabilidades. Os que mais aparecem: verificação de autorização ausente em rota nova, acesso a recurso por identificador sem checar dono, consulta montada por concatenação, segredo indo para log, ausência de rate limiting em endpoint público e dependência puxada em versão vulnerável porque era a do exemplo. Nada disso quebra em teste funcional.
Quando o volume de código por sprint dobra, a superfície de ataque acompanha. Revisão de segurança orientada por OWASP precisa entrar no fluxo da sprint, não em uma auditoria anual, e checagem automática de dependência e de segredo precisa estar no pipeline, bloqueando merge. É mais barato do que a alternativa por uma ordem de grandeza.
A sprint muda de forma, não de duração
O peso migra do meio para as pontas. Planning encurta, porque estimativa de tempo de implementação perde boa parte da relevância. Refinamento cresce, fica mais técnico e passa a produzir especificação de verdade, não título de tarefa. O limite de trabalho em progresso precisa ser recalculado a partir da capacidade de revisar e validar, não da capacidade de escrever. Review deixa de ser demonstração e vira decisão de negócio explícita: isso resolve a dor que motivou a tarefa? A retrospectiva ganha uma pergunta nova e incômoda: onde o assistente nos levou para o lugar errado, e por que o contexto que demos permitiu isso?
O time que apenas trocou o editor por um assistente e manteve a cerimônia intacta ganha velocidade local e nenhuma velocidade de entrega. É o padrão mais comum de frustração hoje: sensação de produtividade individual alta, com prazo de entrega igual ao do ano anterior.
O que medir daqui para frente
Linhas de código e pontos concluídos ficam ainda menos úteis do que já eram, porque agora medem o que ficou barato. As métricas que continuam dizendo a verdade são as de fluxo e de estabilidade: lead time do pedido até produção, frequência de deploy, taxa de falha em mudança e tempo de recuperação. A elas vale somar duas específicas deste contexto: retrabalho após validação de negócio e quantas tarefas voltaram por especificação incompleta. Essa última é o termômetro mais honesto que existe para saber se o refinamento acompanhou a nova velocidade.
O sinal de alerta é simples. Se o throughput subiu e o retrabalho subiu junto, o time não ficou ágil, ficou apenas mais rápido em produzir dúvida.
Como conduzir a transição sem perder o controle
Na Alcance Tech, a I.A. entra dentro do processo, nunca no lugar dele. Os papéis seguem explícitos e separados de propósito: o P.O. traduz dor de negócio em especificação enraizada no domínio, o desenvolvimento entrega em fatias verticais testáveis copiando os padrões da base, o Q.A. valida de forma independente antes de qualquer coisa ser chamada de pronta, e segurança e experiência de uso entram como consultores nas partes que merecem. O que se ganha não aparece na quantidade de código produzido, aparece no tempo entre identificar uma dor e ter a solução em produção, com rastro de decisão auditável do requisito ao deploy.
A promessa da agilidade com I.A. não é fazer o mesmo processo em menos tempo. É reconhecer que, quando implementar fica barato, decidir bem e verificar bem passam a ser o trabalho.
