A velocidade não é o problema: maturidade de engenharia na era do SDLC agêntico

Quando qualquer ideia vira software em poucos dias, o que separa uma solução de um passivo não é a ferramenta, mas a maturidade de engenharia que a sustenta.

De assistentes a agentes: quatro anos que reescreveram o desenvolvimento de software

Entre 2022 e 2023, a IA generativa entrou nas equipes de engenharia pela porta mais simples: a janela de chat. Desenvolvedores copiavam trechos de código para uma conversa, recebiam sugestões e as colavam de volta no editor. O ganho era real, porém pontual, e dependia quase inteiramente da habilidade de quem formulava a pergunta.

O passo seguinte levou a IA para dentro da IDE, com assistentes de autocompletar cientes do contexto do arquivo. Logo depois surgiram as ferramentas agênticas, capazes de ler um repositório inteiro, editar dezenas de arquivos, executar testes e iterar sobre os próprios erros. Em 2026, uma área de engenharia de grande porte opera, em média, perto de cinco ferramentas de IA diferentes em paralelo ao longo do ciclo de desenvolvimento.

O próximo ciclo muda o centro de gravidade. Agentes deixam de ser acionados por uma pessoa e passam a ser disparados por eventos e, nas organizações mais avançadas, corrigem o problema de forma autônoma antes que alguém o veja. A adoção segue a curva clássica de difusão de tecnologia: a maioria das empresas está hoje entre os assistentes e as ferramentas agênticas, e apenas uma minoria já opera agentes integrados ao SDLC.

A consequência é que a pergunta estratégica mudou de natureza. Até aqui, o debate girava em torno da produtividade individual: quanto mais rápido um desenvolvedor escreve código com apoio de IA. Daqui em diante, o debate é sobre o sistema e essa é uma questão de engenharia e de governança antes de ser uma questão de ferramenta.

Uma ideia vira solução em uma semana. E depois?

O custo de produzir código despencou. Hoje, um gerente de produto com acesso a uma plataforma agêntica transforma uma hipótese em protótipo funcional em dias, e uma equipe de engenharia experiente faz o mesmo em horas. O que ficou caro não foi escrever software, mas confiar no software escrito.

Considere um diretor comercial de um banco que, em um fim de semana, constrói com apoio de IA um simulador de limite de crédito para a força de vendas. Na demonstração, tudo funciona. Para ir a produção, porém, a aplicação precisa autenticar usuários corporativos, integrar-se ao core bancário, registrar trilha de auditoria para o regulador, tratar dados pessoais conforme a LGPD, suportar picos de uso no fechamento do mês e ter um dono que responda por ela às três da manhã. A distância entre a demo e o sistema é, exatamente, a maturidade de engenharia da organização.

Há ainda um efeito menos visível. A IA acelera tarefas isoladas mas o trabalho continua parado entre as etapas: aguardando a próxima sprint, a revisão de um especialista, a aprovação de uma mudança. Quando o volume de código gerado cresce mais rápido do que a capacidade de revisar, testar e operar, o gargalo apenas muda de lugar, e o lead time de uma funcionalidade, do pedido à produção, praticamente não se move.

É por isso que escalar IA no desenvolvimento exige um SDLC bem resolvido. Em um cenário em que qualquer ideia pode virar aplicação em menos de uma semana, a vantagem competitiva não está em produzir mais soluções, mas em produzir soluções que resolvem o problema de forma escalável, segura e governada.

Dois caminhos para a IA no SDLC: assistido e agêntico

Nem toda adoção de IA no desenvolvimento é igual, e confundir os dois caminhos é a origem de boa parte das frustrações corporativas. No SDLC assistido, a IA apoia pessoas que continuam conduzindo cada etapa; no SDLC agêntico, agentes executam etapas inteiras e as pessoas passam a definir intenção, limites e critérios de aceite.

A linha mais importante da tabela é a penúltima. No caminho assistido, a qualidade do resultado é limitada pelo modelo; no caminho agêntico, ela é determinada pelo harness

Uma analogia ajuda a dimensionar o desafio: engenharia agêntica se parece com engenharia nuclear. Bem projetada e operada com disciplina, gera energia para uma cidade inteira; conduzida sem controles, causa danos proporcionais ao seu poder. O caminho agêntico não é desaconselhável mas só entrega valor sobre uma base de engenharia madura.

O custo que não aparece na planilha: vibe coding democratizado

Poucas promessas são tão sedutoras para um conselho de administração quanto esta: qualquer área de negócio poderá construir as próprias aplicações conversando com uma IA, sem fila de TI e sem depender de engenheiros. Plataformas de vibe coding corporativo, construtores de agentes sem código e assistentes embutidos em ERPs e CRMs tornaram essa promessa tecnicamente viável. O que raramente entra na análise é a conta que chega depois.

A mudança silenciosa no modelo de custo

Na geração anterior de ferramentas, o custo de software era majoritariamente fixo: licenças por usuário, previsíveis e orçamentáveis. Na geração agêntica, uma parcela crescente do custo é variável e cobrada por token processado. Entre 2025 e 2026, a fatia de tokens no orçamento de engenharia de software nativa em IA passou de 17% para 21%, enquanto a fatia de licenças caiu.

O ponto crítico é que o custo de token não é proporcional ao valor entregue, mas à ineficiência do processo. Um pedido vago faz o agente carregar contexto excessivo, produzir um resultado errado e recomeçar; cada nova tentativa recarrega o contexto inteiro. É o chamado loop de reprompt: descrever, esperar, rejeitar, descrever de novo. Quem conhece engenharia quebra o problema, escreve o teste antes, fornece contexto mínimo e direcionado e deixa o agente validar o próprio trabalho com ferramentas.

Os números de uma sessão típica de correção de um fluxo de autenticação, com um modelo de fronteira, tornam a diferença concreta. No fluxo indisciplinado, são cerca de 15 tentativas, 2,6 milhões de tokens de entrada e algo entre US$ 65 e US$ 75 por sessão. No fluxo disciplinado, a mesma tarefa é resolvida em 3 ciclos, com cerca de 60 mil tokens de entrada e US$ 2 a US$ 3 por sessão.

A diferença não está no modelo, que é o mesmo nos dois casos, mas no método de quem o conduz.

Por que o vibe coding democratizado amplifica o problema

O usuário de negócio que constrói uma aplicação por conversa não está sendo descuidado: ele simplesmente não tem as ferramentas mentais de quem foi treinado em engenharia. Decompor um requisito ambíguo, definir critérios de aceite verificáveis e diagnosticar a causa de um erro em vez de pedir “conserte” são justamente as competências que mantêm o agente fora do loop de reprompt. Sem elas, o caminho indisciplinado deixa de ser exceção e vira o padrão estrutural de uso.

A escala faz o resto. Uma iniciativa de democratização raramente envolve 40 pessoas; envolve 400 ou 4.000. Se o padrão de 40 usuários em uso diário indisciplinado custa perto de US$ 740 mil por ano, a mesma lógica aplicada a 400 usuários com intensidade comparável ultrapassa US$ 7 milhões anuais.

Os tokens são só a ponta do iceberg

O cálculo honesto do retorno de IA no desenvolvimento desconta as horas de atrito das horas economizadas:

ROI = [(horas economizadas − horas de atrito) × custo-hora] − (licenças + tokens + APIs)

As horas de atrito são o tempo gasto corrigindo código gerado por IA nas semanas seguintes à entrega, revisando pull requests inflados e apagando incêndios em produção causados por código que ninguém entendia por completo. Em aplicações construídas fora da engenharia, somam-se ainda a remediação de vulnerabilidades, a sustentação de aplicações cujo autor mudou de área e, no limite, a reescrita completa quando um app departamental se torna crítico para o negócio.

O padrão não é novo. As grandes empresas viveram o mesmo ciclo com planilhas cheias de macros e bancos de dados departamentais: soluções nascidas para resolver um problema local que, anos depois, sustentavam processos críticos sem documentação, testes ou dono. A diferença é que, com IA agêntica, esse ciclo acontece em semanas, em volume muito maior, e com acesso a dados e sistemas que uma planilha jamais alcançaria.

Governar sem proibir

A resposta madura não é vetar o vibe coding, mas calibrar o grau de governança pela criticidade de negócio e pela complexidade de cada aplicação. Ferramentas pessoais e de pequenos grupos, de baixa complexidade, podem ser autogovernadas; aplicações departamentais exigem business case explícito, regras de acesso a dados e monitoramento contínuo; e tudo o que se torna crítico para a empresa sai do território do cidadão desenvolvedor e entra no portfólio de engenharia, com as mesmas práticas exigidas de qualquer software de produção.

O valor dessa matriz está menos na classificação inicial e mais na migração: a governança precisa detectar quando uma aplicação muda de quadrante e movê-la para o regime adequado antes que o custo de corrigi-la exploda.

Maturidade de engenharia: o que separa o protótipo do sistema

Se o diferencial migrou do modelo para o ambiente que o envolve, maturidade de engenharia passa a ter um significado bastante concreto. Não se trata de adotar mais ferramentas, mas de construir as condições para que qualquer código chegue à produção com as mesmas garantias. Cinco capacidades sustentam essa base.

1. Harness engineering: o ambiente em torno do modelo

O harness reúne tudo o que orienta e restringe o agente: o contexto que ele recebe, a escolha do modelo adequado a cada tarefa, a decomposição do trabalho, as ferramentas que ele pode acionar e as verificações que validam cada passo. Organizações maduras tratam o harness como um produto interno, com dono, roadmap e melhoria contínua, em vez de deixar que cada desenvolvedor configure o seu da própria maneira. Na prática, isso combina uma plataforma de agentes adquirida no mercado com uma camada própria de instruções, padrões de código, habilidades reutilizáveis e integrações.

2. Gestão de contexto como disciplina

Contexto é o insumo mais caro e mais mal gerido do desenvolvimento agêntico. Uma regra simples organiza o tema: o que o agente precisa sempre fica em um arquivo de instruções do repositório; o que vale para tarefas específicas fica em regras modulares; fluxos recorrentes viram habilidades empacotadas; e conhecimento grande ou volátil é consultado sob demanda via APIs. A regra mais valiosa, porém, é outra: o que pode ser verificado de forma determinística não deve ser pedido ao modelo, e sim imposto por automação, que é mais barata e não erra.

3. Desenvolvimento orientado a especificação

No SDLC agêntico, o papel humano se desloca da implementação para a articulação da intenção. A pessoa define objetivos, necessidades do usuário, critérios de aceite, escolhas tecnológicas e limites organizacionais; o agente implementa ancorado nessa especificação e atualiza o contexto à medida que aprende. Requisitos deixam de ser documentos estáticos e passam a ser visões de um corpo de conhecimento vivo sobre o produto, alimentado por entrevistas, chamados de suporte, incidentes e decisões de arquitetura.

4. Confiança zero e invariantes não negociáveis

Código é código, independentemente de quem o escreveu. Por isso, organizações maduras definem um conjunto de invariantes que todo artefato precisa satisfazer e os impõem em três pontos de controle: durante a geração, antes do commit e no pipeline de integração e entrega. Agentes rodam em ambientes isolados por padrão, com acesso restrito a sistemas e dados críticos e trilha completa de auditoria.

5. Confiança conquistada, não presumida

A automação da revisão deve crescer na mesma medida em que o agente demonstra confiabilidade. Em ambientes de baixa confiança, toda iteração de código e de teste passa por revisão humana; em confiança intermediária, parte da revisão é automatizada; em alta confiança, a revisão humana se concentra na especificação e nas decisões de arquitetura. Ferramentas de pipeline e revisão assistida por IA podem reduzir de 60% a 75% do esforço manual de revisão, liberando especialistas para o que só eles fazem bem: lógica de negócio, fronteiras do sistema, riscos e trade-offs.

Times menores, papéis mais densos

A transformação não termina no processo; ela alcança o desenho das equipes. O modelo ágil clássico, com oito ou nove pessoas e fronteiras rígidas entre produto, UX, desenvolvimento e qualidade, cria esperas inevitáveis entre especialidades. No modelo nativo em IA, equipes de três ou quatro pessoas, apoiadas por agentes e por um time de plataforma, se organizam em torno de competências, e não de cargos.

Os papéis se comprimem. O product designer traduz jornadas de usuário em contexto para o design gerado por IA; o product architect converte objetivos de negócio em arquitetura; o product engineer transforma intenção em lógica executável, orquestra agentes e valida o que eles produzem; e o quality & context engineer garante a qualidade dos insumos e a confiabilidade das saídas. Em uma multinacional de serviços que adotou esse modelo, os pilotos registraram redução de 28% no tempo de ciclo e de 30% nos defeitos que escapavam para homologação e produção.

A demanda por perfis acompanha o movimento: 72% das lideranças de engenharia esperam ampliar o quadro de engenheiros de IA, e cerca de metade pretende contratar mais engenheiros de plataforma e de segurança. Não é coincidência que as três funções mais demandadas sejam justamente as que constroem e protegem o harness.

As competências que não podem atrofiar

Há habilidades que podem ser delegadas à IA sem prejuízo: sintaxe, código repetitivo, consulta a assinaturas de API, integrações rotineiras. Há outras que precisam ser deliberadamente protegidas, porque são elas que tornam possível dirigir e auditar o trabalho dos agentes: decompor requisitos ambíguos, compreender e explicar código, rastrear o comportamento de um sistema, avaliar se os testes são suficientes e depurar problemas desconhecidos.

A diferença está no modo de uso. Pedir à IA que explique um conceito, ou gerar código e depois reconstruir por que ele funciona, preserva a formação técnica; delegar a tarefa e aceitar o resultado, ou devolver cada erro ao agente sem diagnosticá-lo, a corrói. Em outras palavras, usar a IA para pensar melhor é muito diferente de usar a IA no lugar de pensar.

Medir valor, não volume

Uma armadilha comum é medir o sucesso da IA pelo volume que ela produz: linhas de código geradas, pull requests abertos, percentual de código escrito por agentes. Essas métricas sobem com facilidade e dizem pouco, porque um aumento de volume também pode significar mais retrabalho, mais revisão e mais dívida técnica. As organizações mais bem-sucedidas medem impacto no cliente e no negócio, e não apenas velocidade de equipe.

Uma progressão em três fases ajuda a organizar a medição. Na fase de adoção, acompanha-se o uso real das ferramentas. Na fase de acurácia, mede-se a qualidade do que é entregue. Na fase de valor, as perguntas passam a ser de negócio:

• Lead time de funcionalidade: quanto tempo uma demanda leva do pedido à produção. Otimizar apenas a geração de código produz ganhos marginais aqui.
• Frequência de implantação: entregas menores e mais frequentes, equilibradas com a capacidade do negócio de absorver mudanças.
• Razão entre inovação e manutenção: se a IA está de fato deslocando capacidade de engenharia da sustentação para a diferenciação.
• Satisfação do cliente e retenção de talentos: sinais tardios, porém indispensáveis para confirmar que o ganho é real e sustentável.

O retorno de IA na engenharia também tem níveis. Na base, está a aceleração de tarefas individuais; acima, o desempenho da entrega de software; depois, o impacto em custo; em seguida, a habilitação de valor de negócio; e, no topo, a criação de novos negócios e modelos de entrega. A maior parte das empresas ainda mede apenas a base da pirâmide.

Conclusão: a velocidade foi democratizada; a maturidade, não

Os próximos anos vão tornar a produção de software ainda mais barata e mais rápida, com agentes cada vez mais autônomos atuando em todas as etapas do ciclo. Essa abundância muda a natureza da vantagem competitiva: quando todos conseguem construir rapidamente, vence quem consegue construir com segurança, escala e previsibilidade de custo. A velocidade foi democratizada; a maturidade de engenharia, não.

Para lideranças de tecnologia e de negócio, isso se traduz em quatro movimentos. Primeiro, tratar o harness de agentes como plataforma corporativa, com dono e investimento próprios. Segundo, impor as mesmas garantias a todo código, venha ele de um engenheiro, de um agente ou de um usuário de negócio. Terceiro, governar o vibe coding democratizado por criticidade e complexidade, com uma visão realista do custo de tokens e de sustentação antes de escalar o acesso. Quarto, medir valor de negócio, e não volume de código.

A triggo.ai apoia grandes organizações nessa transição: do diagnóstico de maturidade do SDLC e da governança de IA ao desenho do harness, da gestão de contexto e das práticas de FinOps para agentes. Se a sua empresa está avaliando como escalar IA no desenvolvimento, vale começar por uma conversa com o time da triggo.ai.