SDLC com IA: quem define o que está pronto?
Agentes escrevem o código e os testes. Quem define o que está pronto? Uma visão da engenharia de qualidade sobre o SDLC com IA: custos, papéis e ciclo.
Índice
Na semana passada, eu estava em uma reunião de liderança quando o VP de Engenharia repetiu a pergunta que seu CFO havia feito no dia anterior:
"Se o código deixou de ser um gargalo, por que precisamos de uma equipe desse tamanho?"
A pergunta é legítima, e as principais empresas e plataformas de tecnologia estão respondendo com estratégias mais ou menos iguais: dar mais autonomia aos agentes, manter mais deles em execução e retirar as pessoas do ciclo.
Ao mesmo tempo, uma segunda orientação chega às mesmas equipes: "Precisamos usar IA para entregar mais, mas sem causar falhas em produção nem vazar algo que não possamos recuperar." Curioso, não é? Entregar mais rápido, melhor e com mais segurança, tudo ao mesmo tempo.
Um SDLC com IA é um ciclo de vida do desenvolvimento de software em que os agentes fazem a maior parte da implementação e as pessoas concentram sua atenção nos pontos de controle: intenção, especificações, verificação e release. A questão em aberto para a maioria das equipes é quem define os critérios verificados nesses pontos.
Se você lidera uma equipe de engenharia que está migrando para um SDLC com IA, este post vai ajudar a lidar com seus desafios e aproveitar seu potencial. Para isso, vamos primeiro conhecer o que dizem as empresas que estão construindo a próxima geração de ferramentas, harnesses e infraestrutura para esta “era da IA”.
Está construindo um SDLC com IA? A Abstracta Intelligence traz contexto de qualidade, limites de segurança e evidências para o SDLC com IA.
Quer saber como criar uma pontuação de “prontidão para release”?
A resposta do setor: concentrar a atenção humana nos pontos de controle
Em agosto de 2026, a Anthropic publicou seu guia de SDLC nativo de IA (também chamado de SDLC agêntico ou Agentic Development Life Cycle, ADLC), descrevendo o modelo que a maioria das equipes está adotando: "a atenção humana se desloca junto com os artefatos". As pessoas deixam de revisar linha por linha e passam a revisar nos pontos de controle.
Dias depois, o Kiro (IDE agêntico da Amazon) publicou a versão mais explícita desse guia que li até agora, incluindo os resultados relatados das próprias equipes da Amazon. A frase de abertura apresenta a tese: o desenvolvimento de software se dividiu entre quem mudou a forma de trabalhar com agentes e quem apenas mudou as ferramentas de programação.
O framework do Kiro tem dez princípios, mas estes quatro foram os que considerei mais valiosos:
- Maximize o tempo dos agentes e minimize seu envolvimento. Pare de enviar prompts e esperar. Dê ao agente uma tarefa longa com validação incorporada, deixe-o repetir o ciclo por trinta minutos ou durante a noite, execute vários em paralelo e revise de forma assíncrona. O limite da sua produção deixa de ser a velocidade com que você digita e passa a ser quantos agentes consegue manter ocupados com trabalho relevante.
- Prepare sua base de código para os agentes e ofereça um ciclo rápido de feedback. Isso é levar o shift-left a sério. Linters, testes unitários, mocks locais, a stack completa em um notebook, testes baseados em propriedades derivados da especificação: o agente tem acesso a tudo isso para encontrar e corrigir suas próprias falhas antes que alguém veja o código. Eu destacaria o alerta deles: gerar mais rápido sem esse investimento significa apenas mais builds com falhas.
- Invista no contexto dos agentes. Arquivos de orientação, decisões de arquitetura documentadas e comentários no código mantidos como memória persistente. Segundo eles, as equipes que pulam essa etapa continuam se perguntando por que o agente repete os mesmos erros.
- Confie nos limites, não no agente. Restrinja o que o agente pode acessar (arquivos, ferramentas, rede e credenciais), exija aprovação apenas para o que não pode ser desfeito, adicione camadas de verificações determinísticas, como SAST e detecção de segredos, e deixe-o trabalhar sem supervisão dentro desses limites.
Os dois documentos acertam em muitos pontos, e os benefícios são reais. Começar até parece fácil: recomendo muito este conjunto de skills de estruturação para cada etapa, que você também pode personalizar para sua base de código, e depois um harness para orquestrá-las sem perder o controle e dar a cada agente especializado o contexto certo.
O que nenhum dos documentos define é quem verifica o ciclo e com quais critérios. Eles dizem onde concentrar a atenção humana, mas não quem a exerce nem o que significa “bom o suficiente” para seu sistema. É essa lacuna que a engenharia de qualidade precisa preencher, e é disso que trata o restante deste post.
🤝 Com o que eu concordaria
Com cerca de setenta por cento. “Confie nos limites, não no agente” é nosso posicionamento em outras palavras, e “explicite a intenção antes do código” é o que chamamos de revisão de intenção. O próprio Kiro diz que isso exige investimento em engenharia, em vez de simplesmente ativar uma opção, e que as primeiras semanas parecem mais lentas. Por isso, insistimos em uma fase de fundação antes de escalar os agentes. E “meça a correção, não apenas a velocidade” é uma frase que eu poderia ter escrito.
Os 30% restantes estão por trás desses dez princípios, e é aí que vejo o maior potencial de impacto. Vamos aprofundá-los por estes ângulos: os custos, os papéis e o ciclo.
🔍 O que está por trás
1. Os custos: é capex, e cresce conforme o que você já opera
O código ficou barato. Os custos não desapareceram: mudaram de lugar e se dividem em três itens.
O primeiro é a fundação. Cada um dos dez princípios exige construir algo antes de obter retorno: arquivos de orientação, uma base de código em que os agentes consigam navegar, testes de propriedades, limites e avaliações. A maioria das equipes que conheci pulou essa etapa e comprou as licenças.
O segundo cresce com sua produção. A Anthropic acaba de publicar seus próprios números, que contam essa história melhor do que eu:
O terceiro é o tempo. O Kiro diz que as primeiras semanas parecem mais lentas; com uma revisão de segurança e um comitê de mudanças, semanas viram trimestres. E o tempo dos agentes só gera ganhos acumulados se os pontos de controle responderem na mesma velocidade: um agente que termina às 2h e espera até segunda-feira não está maximizando nada.
O tamanho dos custos depende do que você já opera. Uma startup que nasce com agentes não tem nada em produção para proteger. Quem opera um sistema central legado, sendo um banco o caso extremo, muda um sistema cujas regras estão na cabeça das pessoas que o mantêm funcionando. O guia é o mesmo; a sequência, o custo e o risco são diferentes.
Por isso, eu responderia ao CFO na linguagem dele. Trate a fundação e a infraestrutura de verificação como capex, amortizado em cada release seguinte. Trate o trabalho dos agentes nas funcionalidades como opex, medido por mudança que você realmente aceita. Quem cuida de cada item?
2. Os papéis: desenvolvedores cuidam do harness, testadores definem o que está pronto
Os documentos dos líderes do setor descrevem bem a mudança do desenvolvedor, e eu acrescentaria mais um degrau:
Escrever código → revisar código → revisar a revisão da IA → melhorar o harness que produz o código.
O setor já tem um nome para esse último degrau: engenharia de ciclos. Projetar o ciclo que o agente executa (agir, verificar com sinais reais, decidir, repetir e parar), em vez de escrever cada instrução manualmente. O décimo princípio do Kiro, “ajuste continuamente a configuração dos agentes”, é esse trabalho, e ele é permanente.
Agora procure o testador nos mesmos documentos. Os testes aparecem como “os testes que o agente escreve”. Especialistas de domínio e engenheiros de qualidade não entram em cena. A história de CI da Anthropic traz um detalhe revelador: o serviço que decide o que será verificado tinha, nas palavras deles, uma responsabilidade pouco clara. O mecanismo que decide o que verificar não tinha responsável.
Isso é um problema, porque o agente que escreve o código também escreve os testes, executa-os e declara sucesso. Quem produz também audita. A OpenAI acabou de mostrar aonde isso leva: durante avaliações internas, um agente explorou uma falha na própria interface de testes para copiar a solução de referência e receber a recompensa, e os agentes raciocinaram sobre o avaliador em vez da tarefa.
Um dos principais laboratórios do mundo respondeu com avaliadores que verificam como uma tarefa foi feita, e não apenas se foi concluída. Em nosso trabalho com agentes, tratamos isso como regra: a autoavaliação do agente nunca é evidência. Só contam verificações determinísticas ou validação humana.
Todo banco já conhece esse princípio como segregação de funções, e o guia da Anthropic o aplica no pull request, em que o agente que escreveu o código não pode aprová-lo. O que fica em aberto é quem decide o que as verificações devem avaliar desde o início.
É aqui que considero a visão dos líderes do setor insuficiente: muitas vezes, o testador tem mais conhecimento de negócio do que qualquer outra pessoa da equipe. Testadores funcionais passam seus dias entendendo a lógica de negócio e o que os usuários realmente precisam. Quando eles não estão presentes, as equipes acabam fazendo UAT com os usuários, o que mostra onde está o conhecimento.
No setor bancário, os testes ainda são o gargalo, e a solução habitual é “preciso de mais um testador”. Isso amplia a execução. Os agentes ampliam a execução melhor. O que não escala é o julgamento: qual módulo afeta reembolsos, qual regra é regulada, qual falha teria impacto. O seletor de testes da Anthropic decide com base no histórico e na relevância dos pacotes, o que é um bom começo; alguém ainda precisa dizer o que importa se houver uma falha.
Portanto, se já houve uma época em que o shift-left é possível, é esta. Todos falam em projetar o ciclo. Nós perguntamos quem projeta a verificação dentro dele: os critérios, o que conta como evidência e quando escalar a questão. Essa é a trajetória do testador, e no topo dela está o engenheiro de qualidade:
Executar testes → projetar testes → projetar a verificação dentro do ciclo → assumir os critérios e as evidências que tornam um release defensável.
Desenvolvedores cuidam do harness; engenheiros de qualidade definem o que está pronto.
Esses dois últimos degraus são a resposta ao CFO. A equipe não diminui porque os agentes escrevem código. Ela muda de formato, porque alguém precisa definir o que está pronto.
3. O ciclo: shift-left agora inclui aprendizado
Shift-left costumava significar testar mais cedo. Com os agentes, ele chega à intenção e à especificação antes de existir uma linha de código: um engenheiro de qualidade revisa uma intenção em busca de ambiguidades, uma análise de risco acompanha a especificação, e critérios de aceitação e propriedades são escritos antes de o agente começar. O que se antecipa é o aprendizado, além dos testes. Cada critério explicitado na intenção é uma coisa a menos para descobrir em um diff.
Outro conselho da Anthropic no post sobre CI: instrumente seus serviços para que se tornem os olhos e os ouvidos dos agentes. Pela perspectiva da qualidade, essa é a maior evolução para os testadores em anos. Os mesmos sinais que permitem a um agente melhorar progressivamente um serviço permitem ao engenheiro de qualidade ver o que mudou, o que foi afetado e como se comportou da última vez em produção, durante os testes, e não depois.
Vimos isso em um sistema de core bancário com centenas de milhares de programas: transformar rastros do sistema em linguagem simples deu aos testadores uma visão do caminho de execução por trás de cada operação que ninguém tinha antes durante os testes, tornando a verificação mais precisa. Observabilidade deixa de ser apenas o dashboard do SRE e passa a ser a camada de evidências usada para avaliar os critérios.
Depois há a metade para a qual ninguém projeta. Tudo acima produz aprendizados: um critério que um testador explicitou, um limite que se mostrou amplo demais, um módulo que falhou por um motivo que ninguém havia documentado. Hoje, a maioria deles se perde ao fim de uma sprint. Eles se tornam ainda mais valiosos quando voltam ao harness, a uma skill ou ao contexto que o agente recebe, no momento em que ele precisa deles. Um aprendizado só tem valor quando está onde a próxima decisão é tomada.
É essa a direção que estamos seguindo com a Abstracta Intelligence: conhecimento de qualidade que não fica na cabeça de uma pessoa nem em uma sprint, mas retorna ao ciclo quando necessário, com autor e data registrados. Isso merece um post próprio, e será o meu próximo.
🧾 As plataformas estão vendo a mesma coisa
Quase ao mesmo tempo que o guia da Anthropic, o CEO do GitLab publicou “Quando o código é abundante”. Seu argumento vem da perspectiva da plataforma: quando a implementação fica barata, a unidade de análise econômica muda. Ela deixa de ser o código produzido e passa a ser o custo de uma mudança que você realmente pode aceitar. E a frase à qual sempre volto é:
“Quando a implementação se torna abundante, a confiança se torna escassa.” — Bill Staples, CEO do GitLab
O GitLab está definindo a direção do produto, e não apenas enunciando um princípio. Quando a empresa que executa seus pipelines decide que o custo de aceitação, em vez dos commits, é o número a otimizar, a defesa da verificação deixa de ser uma opinião da equipe de qualidade.
Eu só acrescentaria a perspectiva da equipe. O custo por mudança aceita mede o que você paga. O que você compra com isso é confiança. Por isso, ao lado de cada dashboard de tempo dos agentes, eu colocaria uma pergunta muito mais simples: de tudo que seus agentes produziram nesta semana, quanto você aceitou sem retrabalho, e conseguiria mostrar as evidências disso ao seu regulador, ao seu CISO e aos seus clientes?
Na Abstracta, resumimos isso em uma frase: a qualidade é como construímos confiança por meio da engenharia.
Perguntas frequentes sobre o SDLC com IA
O que é um SDLC com IA?
O ADLC não é o SDLC tradicional com IA no ciclo: é um processo diferente, redesenhado considerando o desempenho dos LLMs de última geração e a IA agêntica. Nesse modelo, a principal unidade de execução é um agente, a grande maioria da implementação é feita por agentes, e as pessoas se concentram nos pontos de controle mais importantes, como intenção, especificações, verificação e release. As fases conhecidas de planejamento, projeto, construção, testes, deploy e manutenção continuam existindo, mas passam a funcionar como um ciclo contínuo de feedback.
Como o SDLC com IA difere do ciclo de vida tradicional do desenvolvimento de software?
O ciclo de vida tradicional do desenvolvimento de software é conduzido por pessoas. O trabalho avança para a próxima etapa por meio de passagens entre diferentes equipes, e as pessoas revisam a maioria dos artefatos linha por linha. Em um SDLC com IA, os agentes escrevem o código e os testes, cada etapa gera um artefato versionado no controle de versão, como arquivos .md de intenção e especificação, e a revisão humana se concentra nos pontos de controle. A fase de construção diminui, o trabalho flui em várias direções, e planejamento, verificação e release se tornam os novos gargalos. A maioria das organizações precisa atualizar sua visão do processo de desenvolvimento para a realidade atual e direcionar o investimento a essas áreas.
O que acontece com as equipes de engenharia quando agentes de programação de IA escrevem a maior parte do código?
Quando agentes de programação de IA assumem a geração de código, tarefas rotineiras e a maioria das tarefas repetitivas, as equipes de engenharia de software mudam de formato. Os desenvolvedores passam de escrever código a revisá-lo, depois a revisar a revisão da IA e, por fim, a melhorar o harness e o ciclo que o produz. Os testadores deixam de executar e projetar testes para projetar a verificação dentro desse ciclo e assumir os critérios e as evidências que tornam um release defensável. Para Fabián Baptista, cofundador e CIO da @Abstracta, a equipe se paga pelo risco que mantém fora do release.
A revisão humana ainda é necessária em um SDLC orientado por IA?
A revisão humana ainda é necessária em um SDLC orientado por IA e funciona melhor quando se concentra nos pontos em que o julgamento importa. Revisões de código linha por linha deixam de escalar quando os agentes produzem a maior parte do diff. Por isso, a supervisão humana passa a pontos de controle específicos: aprovação de intenções e especificações, mudanças em sistemas de produção, tudo que envolve dados sensíveis e decisões que só pessoas devem tomar porque não podem ser desfeitas. Equipes de segurança, responsáveis pelo produto e engenheiros de qualidade mantêm a decisão final nesses pontos; verificações determinísticas cuidam da verificação rotineira entre eles, e a intervenção humana fica reservada ao que sistemas autônomos não devem decidir sozinhos. Na Abstracta, projetamos esses pontos com cada equipe, começando pelo que não pode ser desfeito em seu contexto. Isso é IA responsável aplicada à entrega de software.
Qual é o papel dos testes no SDLC com IA?
O papel que defendemos há anos para os testes: engenharia de qualidade, a disciplina que define o que está pronto e como isso é comprovado. O SDLC com IA não cria essa necessidade; elimina a desculpa. Os agentes geram e executam testes mais rápido do que qualquer equipe, então executar testes deixa de ser onde os testadores agregam valor, e assumir os critérios passa a ser o trabalho. A oportunidade é maior do que parece, porque os agentes também permitem aos testadores fazer o que antes não podiam: ler uma mudança de código e entender o que ela afeta, acompanhar sinais de observabilidade e rastros em linguagem simples e ver como um módulo se comportou em produção durante os testes, e não depois. É o shift-left chegando à intenção e à especificação, nas mãos das pessoas que já detêm o maior conhecimento de negócio da equipe. Na Abstracta, trabalhamos com equipes de testes para fazer essa transição: de executar testes a assumir os critérios e as evidências por trás de cada release.
Como o desenvolvimento orientado por especificações se encaixa no SDLC com IA?
O desenvolvimento orientado por especificações é o ponto em que o shift-left chega à intenção. Antes de um agente escrever qualquer código, a equipe transforma ideias de produto, feedback dos usuários e contribuições dos stakeholders em uma especificação que o agente consegue ler: intenção de negócio, requisitos, casos extremos e critérios de aceitação. A IA pode elaborar essa especificação a partir do que já está documentado. O problema é o que não foi documentado, e nos sistemas legados isso representa a maior parte: as regras estão na cabeça das pessoas que mantêm o sistema funcionando. Por isso, na Abstracta acrescentamos uma revisão de intenção, em que um engenheiro de qualidade verifica ambiguidades, consulta quem conhece as regras e anexa uma análise de risco antes de o agente começar. Cada critério explicitado na intenção é uma coisa a menos para descobrir em um diff.
O que as equipes de engenharia devem construir antes de escalar agentes de IA?
Antes de escalar agentes de IA, as equipes de engenharia precisam de uma fundação em cada parte do fluxo de trabalho em que eles atuam: contexto e arquivos de orientação (CLAUDE.md no Claude Code, arquivos de orientação no Kiro), decisões de arquitetura documentadas, uma base de código que os agentes consigam compilar e testar localmente, testes baseados em propriedades derivados da especificação, limites claros sobre o que os agentes podem acessar e avaliações que verifiquem os próprios agentes. Vale destacar o alerta do Kiro: gerar mais rápido sem esse investimento significa apenas mais builds com falhas. As primeiras semanas parecem mais lentas, por isso tratamos a fundação como capex, amortizado em cada release seguinte, em vez de algo que se ativa simplesmente ao comprar as licenças.
Como as equipes devem medir o impacto da IA na entrega de software?
As equipes devem medir o impacto da IA na entrega de software pelas mudanças que realmente aceitam, em vez do volume produzido pelos agentes. Métricas úteis: custo por mudança aceita, a proporção da produção dos agentes aceita sem retrabalho, o custo total de verificação por release antes e depois dos agentes, e se as evidências de cada release resistiriam à análise de um regulador, de um CISO ou de um cliente. Dashboards de tempo dos agentes e métricas de velocidade continuam úteis, mas apenas ao lado dessas medidas. Velocidade medida sem qualidade mostra a rapidez com que você produz coisas que talvez não consiga entregar.
Como as equipes podem evitar que os aprendizados se percam entre sprints?
As equipes podem evitar a perda dos aprendizados colocando cada um de volta onde a próxima decisão é tomada. Um critério que um testador explicitou, um limite que se mostrou amplo demais ou um módulo que falhou por um motivo que ninguém havia documentado devem voltar ao harness, a uma skill ou ao contexto do agente, com autor e data registrados. Essa é a direção da Abstracta Intelligence, nossa plataforma corporativa de IA construída sobre o Tero, nosso framework agêntico open-source, para que o conhecimento de qualidade continue disponível para a melhoria contínua.
Como a Abstracta pode ajudar as equipes a adotar um SDLC com IA?
A Abstracta ajuda equipes de engenharia a adotar um SDLC com IA, assumindo a parte que a maioria dos guias deixa em aberto: os critérios, a verificação e as evidências que determinam se a produção dos agentes está pronta para entrega. Começamos com uma fase de fundação e depois trabalhamos ao lado de desenvolvedores e engenheiros de qualidade para projetar a verificação dentro do ciclo, com apoio da Abstracta Intelligence e do Tero, nosso framework agêntico open-source. Com quase 20 anos em engenharia de qualidade e experiência em ambientes complexos, como sistemas de core bancário, ajudamos as equipes a avançar mais rápido mantendo o controle do que chega à produção. É a mesma lógica da resposta ao CFO: em um grande banco da América Latina, triplicamos a cobertura de QA, de 6 para 18 projetos, sem crescimento proporcional da equipe. A equipe não diminuiu. Mudou de formato.
O que eu levaria de tudo isso
Os custos. Maximize o tempo dos agentes e trate a fundação e a verificação como o capex que são. O trabalho dos agentes é opex, medido por mudança que você realmente aceita.
Os papéis. Desenvolvedores cuidam do harness e do ciclo. A trajetória do testador chega a um engenheiro de qualidade que projeta a verificação dentro desse ciclo e assume as evidências, porque quem produz não pode auditar.
O ciclo. Shift-left agora inclui aprendizado: critérios na intenção, observabilidade como camada de evidências e o que você aprende voltando ao lugar onde a próxima decisão é tomada.
É assim que “entregar mais rápido, melhor e com mais segurança” deixa de representar três orientações conflitantes. E essa é a resposta ao CFO que se sustenta: a equipe se paga pelo risco que mantém fora do release, não pelo código que já não digita.
Se sua equipe já executa agentes durante a noite: quem escreveu os critérios pelos quais são avaliados, quem verificou os testes que eles escreveram e para onde vão os aprendizados pela manhã para melhorar o ADLC a cada dia?
Na Abstracta, ajudamos equipes de engenharia a responder a essas três perguntas com evidências. Trabalhamos ao lado de desenvolvedores e engenheiros de qualidade para definir os critérios de avaliação dos agentes, projetar a verificação dentro do ciclo e devolver ao contexto dos agentes o que cada release ensina, com apoio da Abstracta Intelligence e do Tero, nosso framework agêntico open-source.
Vamos conversar sobre seu harness e como criar um SDLC com IA sólido
Fique conectado
com a Abstracta
Notícias, artigos e recursos para construir software melhor.
Leia sobre nossa política de privacidade.
