Porque é que os agentes de programação com IA não chegam para apps em produção

Comecemos por ser justos com a categoria. Os agentes de programação modernos, Cursor, Claude Code, OpenAI Codex e os seus pares, são ferramentas genuinamente fortes. Leem bases de código grandes, planeiam alterações multificheiro, escrevem testes, corrigem falhas e iteram até as coisas passarem. As equipas de engenharia que os usam bem andam visivelmente mais depressa, e nada neste artigo defende o contrário. A questão é de âmbito, não de qualidade.

O resultado de um agente de programação, por melhor que seja, é uma alteração ao código. O software de produção é um sistema muito maior de obrigações permanentes: provar que a alteração funciona para utilizadores reais, verificar que não introduziu nenhuma vulnerabilidade, decidir se era sequer permitida, lançá-la em segurança, reparar quando se comporta mal e reconstruir o que aconteceu quando isso acontece. Cada uma dessas obrigações existe quer alguém esteja atribuído a ela quer não, e um agente de programação, a operar na fase de edição do código, não o dispensa de nenhuma. Aumenta a pressão sobre todas, porque a fase que acelera é a que alimenta todas as outras.

Assim, a pergunta prática para uma equipa a caminho da produção não é "o nosso agente é suficientemente bom?". É "quem é dono de tudo o que está a jusante do diff, agora que os diffs chegam cinco vezes mais depressa?". As equipas com uma organização de plataforma forte respondem com infraestrutura que já operam. As equipas sem uma precisam de construir esse ciclo ou de o adotar, e devem decidir deliberadamente, não descobrir a lacuna durante um incidente.

Ajuda perceber porque é que a lacuna é tão fácil de não ver. O resultado do agente é vívido. Uma funcionalidade a funcionar, uma execução de testes a passar, um ticket fechado. Enquanto o ciclo em falta é invisível até ser posto à prova: ninguém vê o teste de navegador que não existe ou o registo de auditoria que nunca foi escrito. As decisões de compra pesam naturalmente o vívido sobre o invisível, e é assim que as organizações acabam com geração excelente e entrega improvisada. Escrever as seis obrigações abaixo na avaliação é a correção; levam uma tarde a avaliar com honestidade e preveem a dor de produção muito melhor do que qualquer benchmark de geração.

Eis o padrão que os líderes de engenharia continuam a relatar. Os agentes chegam; o volume de pull requests salta em semanas; e cada fase a jusante, revisão, QA, segurança, lançamento, passa de repente a ser a restrição. A organização deriva então para um de dois modos de falha. Ou as fases a jusante aguentam a linha e a fila reforma-se à frente delas, o que significa que o ganho de produtividade se evapora em tempo de espera; ou as fases cedem, as aprovações tornam-se mais leves, os testes saltam-se "só desta vez", e a organização passa efetivamente a entregar código sem revisão em escala, sem nunca o ter decidido.

O segundo modo é o perigoso, porque parece sucesso. O lead time cai, os painéis brilham, e o risco acumulado é invisível até uma terça-feira específica: uma migração escrita por um agente, aprovada em nove segundos por um revisor com quarenta separadores abertos, deita abaixo o fluxo de checkout, e o postmortem descobre que não há nenhum teste em navegador para o checkout, nenhuma política que sinalize alterações de esquema para revisão a sério, e nenhuma forma limpa de saber qual dos duzentos merges da semana reverter.

Nada disso é culpa do agente. Todas as salvaguardas em falta já faltavam antes de o agente chegar; havia simplesmente menos trânsito sobre a ponte. A assimetria é o ponto: ferramentas que multiplicam a produção de código multiplicam as consequências do que quer que falte ao seu ciclo de entrega.

Se quer aviso prévio em vez de um postmortem, observe quatro números à medida que a adoção de agentes cresce: o tempo mediano de revisão por alteração integrada (colapsar em direção a zero é um sintoma, não uma vitória), a cobertura de testes dos fluxos que carregam receita, o tempo médio para atribuir um problema de produção à alteração que o causou, e a percentagem de deploys com um caminho de rollback testado. Qualquer um deles a mover-se na direção errada enquanto o volume de merges sobe é a assimetria a chegar dentro do horário, e os quatro são mais baratos de corrigir no mês dois do que no mês doze.

Caminho um: montar o ciclo por conta própria. CI com gates a sério, infraestrutura de testes em navegador, análise de segurança ligada a algo que verifique os resultados, políticas de revisão que a sua equipa realmente faça cumprir, automação de implementação com rollback, observabilidade, e a cola para fazer as alterações geradas por agentes fluir por tudo isso. É um caminho legítimo, é o que as equipas de plataforma fortes fazem, e o seu custo é ser um investimento de engenharia permanente, não uma compra. Se tem a organização de plataforma para o construir e manter, agentes de programação dentro desse ciclo são uma combinação soberba.

Caminho dois: adotar uma plataforma em que o ciclo é o produto, e a geração acontece dentro dele. Este é o compromisso que a maioria das equipas sem organização de plataforma devia avaliar com honestidade: menos controlo à medida do que construir o seu, em troca de testes, governança, segurança, implementação e monitorização que existem no primeiro dia e escalam com o volume de alterações por construção. Os dois caminhos também não são inimigos. Muitas organizações mantêm engenheiros com agentes de programação nos sistemas centrais e uma plataforma governada para a longa cauda de aplicações de negócio que de outra forma nunca receberiam atenção da equipa de plataforma.

Uma heurística justa para escolher entre os caminhos: conte os seus engenheiros de plataforma e as suas aplicações. Uma equipa de plataforma forte a suportar uma mão-cheia de sistemas centrais consegue perfeitamente construir o ciclo, e provavelmente deve. A mesma equipa, obrigada a estender esse ciclo por dezenas de apps departamentais, portais construídos por agências e heranças de aquisições, vai afogar-se. Essa longa cauda é onde a decisão de comprar normalmente se paga. E os caminhos compõem-se: nada na adoção de uma plataforma para o portefólio exige abandonar o pipeline em que o seu produto principal já confia.

O Ciao é o caminho dois, construído deliberadamente. Cada workspace recebe uma organização de software com IA. CTO, Doctor, analista de QA, engenheiro de Segurança, Coder e operador de SysOps. Para que os papéis donos do ciclo existam desde o primeiro prompt. O QA executa repetições determinísticas em navegador, testes autorreparáveis, smoke gates antes da publicação e verificações de produção depois da publicação. O Security executa análise estática, verificação de dependências e sondagens de controlo de acesso, e confirma vulnerabilidades contra a app ao vivo antes de as sinalizar. O Guardrails aplica políticas em linguagem simples, regista a revisão humana e deixa um registo de auditoria por trás de cada merge. O Doctor, um SRE de IA apenas de leitura, sonda a app ao vivo, o DNS e o CDN, diagnostica a causa raiz e elabora a correção, e o Conductor dá um ecrã sobre toda a frota.

E porque a fase de edição de código não deve ser um jardim murado: as aplicações são React, TypeScript e Supabase reais com 100% de propriedade, exportáveis para o seu próprio repositório a qualquer momento, e as imagens de sandbox personalizadas envolvem o mesmo ciclo de vida à volta de Rails, Java, Go, Python, Node e backends multi-processo. Implemente na nuvem Ciao, na sua própria conta AWS, Azure ou GCP, numa VPC privada ou on-premise sob termos separados. Os programas de desenvolvimento sérios começam em 10.000 USD por ano, e a demonstração mais útil, se este artigo lhe soou familiar, é ver uma alteração percorrer o ciclo inteiro do prompt à produção monitorizada.