O grande aumento da velocidade de escrita de software já não é o único desafio diante das equipes de desenvolvimento. Com a transição de ferramentas como o Cursor, que passaram de sugestões de código dentro do ambiente de desenvolvimento para a execução de tarefas completas a partir de especificações e tickets, o problema pode passar a ser a capacidade da organização de determinar o que vale a pena construir, testar e implantar com segurança, e depois operar e manter.
Esse é o foco da apresentação de Hannah Foxwell intitulada «Reinventando a equipe de desenvolvimento», que se concentra mais no impacto da programação agêntica sobre as pessoas e os processos do que nas capacidades dos próprios agentes. Foxwell estrutura seu argumento em torno de três pilares que, em sua visão, continuam importantes independentemente da aceleração das ferramentas.
Da falta de velocidade ao excesso de capacidade
Foxwell descreve uma trajetória que começou com equipes lançando software duas vezes por ano e depois passou, por meio de Agile, computação em nuvem, DevOps e entrega contínua, a múltiplas implantações diárias. Ela considera que aquilo que antes era apresentado como uma meta distante — a alta velocidade — começou a se tornar uma realidade que as organizações ainda não sabem como aproveitar.
No modelo de programação agêntica, os agentes podem decompor especificações, escrever código e testes e, depois, ajudar na implantação e no monitoramento. Mas essa capacidade pode criar uma pressão inversa sobre a gestão de produto: as equipes de desenvolvimento podem executar o trabalho mais rapidamente do que a organização consegue fornecer requisitos claros e qualificados. Por isso, Foxwell não considera que a solução seja aceitar toda ideia ou solicitação, pois isso pode levar a produtos inchados e sem foco.
Primeiro pilar: construir o que vale a pena construir
Foxwell enfatiza que o código não é o objetivo, mas um meio de resolver um problema real do usuário. Com a redução do custo de testar ideias, torna-se melhor criar protótipos e experimentá-los com os usuários antes de transformá-los em um compromisso de longo prazo dentro do produto.
Entre os modelos apresentados pelo artigo está o «gerente de produto que programa protótipos», para encurtar a distância entre a ideia e o teste, ou a parceria entre um gerente de produto e um desenvolvedor quando a ideia ultrapassa as capacidades da prototipagem rápida. O artigo também aponta o papel do engenheiro de campo, um engenheiro que trabalha próximo do cliente e tem autonomia para resolver seus problemas, e do «engenheiro de produto», que participa da definição do produto por ser seu usuário ou estar próximo de seus usuários.
Foxwell apresenta experimentos de revisão do tamanho e da proporção das equipes. Em vez do modelo de equipe formada por seis a oito desenvolvedores e um gerente de produto, algumas organizações testam equipes menores, enquanto Andrew Ng propôs um modelo inverso, com dois gerentes de produto para um desenvolvedor capaz de coordenar uma frota de agentes. Esses modelos não são apresentados como regras fixas, mas como experimentos que refletem a mudança do ponto de estrangulamento: da capacidade de desenvolvimento para a clareza dos requisitos e a velocidade das decisões.
Em contrapartida, o artigo alerta contra práticas como lançar uma funcionalidade e passar imediatamente para outra tarefa sem revisar seu uso, aceitar toda solicitação de cliente ou usar a opinião do executivo mais bem remunerado como critério de prioridade. Em um ambiente no qual escrever software se torna mais rápido, a pesquisa com usuários, a experiência de uso e a capacidade de verificar o valor podem se tornar fatores de diferenciação mais importantes do que a própria velocidade de execução.
Segundo pilar: velocidade precisa de segurança
O aumento no volume de mudanças exige um pipeline de produção capaz de acompanhá-lo. Foxwell alerta que lacunas na cobertura de testes e etapas manuais podem transformar o pipeline de implantação em um ponto de estrangulamento, fazendo com que as mudanças se acumulem antes de chegar aos usuários.
Por isso, o artigo associa velocidade a testes automatizados, mencionando exemplos de uso de agentes na criação de testes contínuos e no auxílio às equipes para lidar com dívida técnica, migrar de plataformas antigas e refatorar bases de código. A ideia não é adicionar inteligência artificial sobre um processo lento, mas reestruturar o caminho até a produção para que ele suporte a nova taxa de mudança.
Foxwell enfatiza que confiabilidade e segurança não são concessões aceitáveis em troca de velocidade. Ela propõe o uso de indicadores, níveis de objetivos de serviço e orçamentos de erro, com uma política escrita que determine o que a organização fará quando o nível aceitável de falhas for ultrapassado, como desacelerar os lançamentos ou direcionar recursos para confiabilidade e resiliência.
Ela também considera que implantação gradual, feature flags, testes A/B e implantação blue-green ajudam a gerenciar muitas mudanças sem expor todos os usuários a elas de uma só vez. O artigo revisita ainda o papel das equipes de engenharia de confiabilidade de sites e das plataformas internas, considerando-as funções consultivas e capacitadoras que oferecem um caminho seguro e preparado para as equipes de desenvolvimento.
O que muda na prática?
A conclusão editorial da apresentação é que os agentes, por si só, não comprovam que as equipes de desenvolvimento ficarão menores ou que os empregos desaparecerão. O que se confirma é que os pontos de estrangulamento mudarão: da produção de código para a escolha dos problemas, a validação do valor, a expansão dos testes, o controle da confiabilidade e a tomada rápida de decisões.
A questão em aberto é se as organizações usarão a nova capacidade para construir produtos melhores e testar suas ideias ou se responderão a ela acumulando mais funcionalidades. As novas proporções entre desenvolvedores, gerentes de produto, equipes de plataforma e equipes de confiabilidade também continuam sendo experimentos, e não resultados comprovados. Por isso, adotar a programação agêntica exige medir seu impacto na qualidade do produto, nos incidentes e na experiência do usuário, em vez de se limitar à quantidade de linhas ou à velocidade dos lançamentos.