Desenvolvimento de software com IA: guia do SDLC

Gerar código ficou rápido. Entender o problema, preservar contexto, revisar riscos e manter o sistema funcionando continuam sendo trabalhos difíceis. O AI-native SDLC playbook da Anthropic propõe reorganizar o ciclo de desenvolvimento de software com IA em torno de artefatos versionados, feedback contínuo e decisões humanas nos pontos que exigem julgamento.

AI-native SDLC é um ciclo de vida de desenvolvimento em que agentes de IA participam de planejamento, design, construção, testes, entrega e manutenção. A diferença principal não está em adicionar um chatbot ao editor. Está em transformar cada etapa em um loop guiado por artefatos, políticas, avaliações e gates humanos.

O SDLC tradicional costuma seguir uma linha: planejar, desenhar, construir, testar, publicar e manter. Cada área recebe um documento, executa sua parte e passa o trabalho adiante. O processo funciona, mas perde contexto nos handoffs. Uma decisão tomada numa reunião pode virar um ticket incompleto, depois uma implementação que ninguém consegue comparar com a intenção original.

O AI-native SDLC tenta fechar essa distância. No playbook da Anthropic, um intent.md registra o problema e o resultado esperado. Depois, um spec.md combina requisitos e desenho técnico. Um plan.md detalha arquivos, ordem de implementação e testes. Cada artefato fica no repositório, sujeito a revisão e histórico.

Segundo a Claude Academy, o modelo organiza seis estágios, Plan, Design, Build, Test, Deploy e Maintain, como um ciclo contínuo. Um artefato aceito aciona o próximo gate, enquanto sinais de produção podem iniciar um novo intent.md. A proposta é operacional, não uma promessa de automatização irrestrita.

O fluxo deixa de depender apenas de pessoas lembrarem regras. Convenções, comandos, políticas de segurança e critérios de revisão passam a existir em arquivos versionados. O agente consulta esse contexto antes de agir. Se a mudança tocar uma área protegida, um hook pode bloquear a operação ou pedir aprovação específica.

Isso também explica a diferença entre usar um copiloto e adotar um AI-native SDLC. Um copiloto ajuda alguém a escrever uma função. Um SDLC com IA define o que precisa ser produzido, como o resultado será avaliado, quem aprova e quais evidências ficam registradas. A ferramenta é parte do sistema, não o sistema inteiro.

A IA transforma o desenvolvimento quando muda a unidade de trabalho. Em vez de apenas linhas de código, a equipe passa a produzir intenção, especificação, plano, evidências de teste e decisões registradas. No playbook da Anthropic, os seis estágios permanecem reconhecíveis, mas deixam de funcionar como caixas isoladas.

O relatório 2026 Agentic Coding Trends, da Anthropic descreve a passagem de assistentes pontuais para agentes capazes de atuar em várias superfícies do desenvolvimento. O documento também ressalta que supervisão e validação continuam necessárias, especialmente quando o impacto de uma falha é alto.

O estágio Plan começa com a pergunta mais esquecida em muitos projetos: qual problema precisa ser resolvido? O intent.md pode reunir objetivo, usuários afetados, restrições, políticas de marca, segurança, compliance e critérios de sucesso. Ele deve ser legível por pessoas e acionável por agentes.

Esse arquivo reduz a chance de o modelo otimizar uma solução para o problema errado. Também permite que produto, engenharia, segurança e dados discutam a mesma referência. Quando uma demanda chega apenas como “criar uma tela” ou “corrigir o pipeline”, faltam contexto e critérios para avaliar se a entrega funcionou.

No Design, o agente lê a intenção, o repositório e as regras organizacionais. A partir disso, produz uma especificação que combina requisitos e desenho técnico. O ponto forte é tornar visíveis as dúvidas. Contradições entre segurança, experiência do usuário e arquitetura aparecem antes do primeiro commit de código.

A pessoa responsável pelo produto ou pela engenharia valida se a especificação resolve a necessidade original. Questões classificadas como de alto risco seguem para os donos das políticas. A aprovação não significa que o agente acertou tudo. Significa que existe uma decisão explícita sobre o que será construído.

No Build, o agente trabalha a partir do spec.md e produz um plano detalhado antes de alterar arquivos. O plan.md registra quais módulos mudam, em qual ordem, quais alternativas foram descartadas e quais testes devem comprovar o comportamento.

O arquivo CLAUDE.md, ou equivalente para outra ferramenta, concentra comandos, arquitetura, convenções e erros recorrentes. Quando o agente comete o mesmo erro duas vezes, a correção pode entrar nesse arquivo. O conhecimento deixa de morar apenas na cabeça de uma pessoa ou em uma conversa perdida.

Testes deixam de ser a última barreira e passam a orientar o trabalho. O agente pode executar lint, testes unitários, integração, build, verificações de contrato e validações visuais. Se o feedback chega enquanto a sessão ainda está ativa, o agente corrige o problema com menos troca de contexto.

A revisão humana continua necessária. Testes automatizados verificam comportamentos definidos, mas não sabem se a regra de negócio está correta. Uma suíte pode passar enquanto um pipeline calcula custo com a métrica errada. É por isso que testes técnicos precisam conviver com avaliações de resultado e revisão da intenção.

No Deploy, agentes podem revisar pull requests em camadas. Uma análise procura bugs e erros lógicos. Outra verifica segurança. Outra compara a implementação com spec.md, plan.md e REVIEW.md. Os achados podem ser classificados por severidade antes de chegar ao revisor humano.

A Anthropic descreve um modelo em que o agente atua até o gate de produção, mas não atravessa sozinho os limites definidos pela organização. Branch protection, code owners, hooks e credenciais com escopo restrito impedem que velocidade vire autorização implícita.

Manutenção é o ponto em que o loop se fecha. Logs, métricas, incidentes, alertas e mudanças no comportamento do usuário podem gerar uma nova intenção. Um desvio recorrente não deve ser apenas um item solto no backlog. Ele pode virar contexto estruturado para a próxima iteração.

O ganho aparece quando produção alimenta planejamento sem criar uma fila paralela de informação. Ainda assim, o monitoramento precisa começar com sinais determinísticos. Um alerta de latência pode chamar um agente para investigar, mas a regra que identifica a deterioração deve ser testável e versionada.

Agentes confiáveis precisam de contexto explícito, permissões mínimas, testes repetíveis, avaliação contínua e aprovação separada da execução. A pergunta não é apenas se o agente consegue concluir uma tarefa. É se a equipe consegue explicar o que ele fez, revisar as evidências e interromper a ação quando o risco ultrapassa o limite definido.

A documentação do Microsoft Foundry recomenda salvar versões, usar tracing, executar avaliações de qualidade e segurança, publicar uma versão estável e monitorar o comportamento em produção. A mesma orientação inclui identidade e permissões, porque ferramentas conectadas ampliam tanto a capacidade quanto o impacto de uma falha.

A primeira prática é escolher uma fonte de verdade. Jira, ServiceNow, GitHub e documentos em Markdown podem coexistir, mas a ligação precisa ser clara. O ticket deve apontar para o intent.md, ou o commit deve registrar o identificador do trabalho. Sem essa relação, a equipe perde a capacidade de responder por que uma mudança foi feita.

A segunda é versionar o contexto. CLAUDE.md, skills, comandos, hooks, políticas e avaliações precisam passar por pull requests. Se a configuração orienta o comportamento do agente, ela merece o mesmo cuidado aplicado ao código. Uma alteração no contexto pode mudar centenas de entregas futuras.

A terceira é limitar permissões. Agentes devem operar com credenciais temporárias, acesso apenas aos repositórios necessários e nenhuma autorização de produção por padrão. O caminho preferível é abrir um pull request, não escrever diretamente na branch principal. Ferramentas de deploy e rollback devem aparecer como ações permitidas, com escopo por ambiente.

A quarta é definir política de revisão. Um REVIEW.md pode estabelecer verificações para segurança, dependências, migrações, dados pessoais, custo de infraestrutura, observabilidade e compatibilidade. O agente que escreve não deve ser a única instância que aprova. Um segundo agente pode revisar, mas decisões classificadas como críticas precisam de uma pessoa responsável.

A quinta é construir avaliações contínuas. Reúna tarefas reais e registre o resultado aceitável para cada uma. A suíte pode verificar testes, lint, comportamento, políticas e ausência de regressões. Toda falha de produção relevante deve virar um caso de avaliação. Assim, o incidente produz aprendizado operacional, não somente uma correção isolada.

Por fim, mantenha rastreabilidade. Registre versão do modelo, versão das instruções, ferramentas usadas, arquivos alterados, testes executados e aprovações. Isso ajuda a investigar incidentes e comparar mudanças. Sem evidência, a organização depende de relatos incompletos justamente quando precisa entender uma falha.

O trabalho muda de implementação isolada para decomposição, orquestração, revisão e responsabilidade técnica. Desenvolvedores passam mais tempo definindo contexto, avaliando planos e verificando resultados. Líderes precisam desenhar limites e métricas. Equipes de dados devem incluir contratos, linhagem, qualidade, custos e segurança no contexto entregue aos agentes.

O relatório da Anthropic sobre coding agentic aponta que agentes ampliam sua atuação entre frontend, backend, bancos de dados e infraestrutura. Isso pode reduzir handoffs, mas também aumenta a superfície de erro. Quanto mais áreas o agente toca, mais clara precisa ser a separação entre executar, verificar e aprovar.

Para o desenvolvedor, a habilidade central deixa de ser apenas escrever uma função rapidamente. Passa a incluir a capacidade de formular um problema, dividir dependências, escolher uma estratégia de teste e identificar quando a saída parece correta, mas não é. Quem entende arquitetura e domínio consegue dirigir melhor o agente.

Para a liderança, o desafio é evitar duas ilusões. A primeira diz que qualquer tarefa pode ser delegada com segurança. A segunda trata uma métrica de linhas geradas como produtividade. Tempo de ciclo, retrabalho, regressões, tempo de revisão e incidentes oferecem uma leitura mais útil sobre o efeito da IA.

Em engenharia de dados, o contexto precisa ser ainda mais preciso. Um agente que altera um job deve conhecer contratos de esquema, regras de qualidade, janelas de atualização, dependências, classificação de dados, custo de consultas e requisitos de linhagem. Um pipeline que termina sem erro pode entregar dados atrasados ou semanticamente incorretos.

Em produtos de dados, entram também definição de métricas, comportamento esperado, grupos afetados e critérios para mudanças de modelo. A IA pode gerar SQL, testes e documentação, mas não decide sozinha qual métrica representa o negócio. Essa escolha exige conhecimento do produto e responsabilidade sobre seus efeitos.

Um exemplo brasileiro ajuda a dimensionar a mudança sem transformá-la em promessa universal. Segundo a Exame, o Bradesco relatou redução de aproximadamente 90% no esforço de tarefas específicas de atualização de sistemas existentes. O fluxo envolvia análise, documentação, alteração, testes e validação humana, especialmente em código crítico.

O caso também mostra por que resultados de uma empresa não podem ser copiados sem contexto. O banco informou que pretende aplicar a abordagem a mais de 350 milhões de linhas legadas e que pilotos otimizaram mais de 20 mil horas. Escala, governança, conhecimento interno e natureza das tarefas influenciam o resultado. Qual é a parte realmente comparável com seu time?

A implementação mais segura começa por um gargalo específico e mensurável. Mapeie onde o trabalho espera, perde contexto ou volta para correção. Depois, escolha um artefato e um gate para melhorar. Uma equipe pequena pode começar com documentação versionada, comandos reproduzíveis e revisão assistida antes de delegar alterações maiores.

A Claude Academy mostra que os estágios são modulares e têm dependências diferentes. Isso permite começar por CLAUDE.md, captura de intenção, hooks ou feedback local, conforme o problema da equipe. Não existe uma ordem universal. A sequência deve respeitar risco, dependências e capacidade de revisão.

Escolha um tipo de trabalho recorrente, como endpoint, transformação de dados, correção de bug ou alteração de infraestrutura. Registre tempo de ciclo, espera por revisão, retrabalho, falhas de teste e incidentes. Observe onde o contexto desaparece. O primeiro experimento precisa ter uma linha de base.

Decida onde vivem intenção, requisitos, decisões e evidências. Pode ser um repositório com Markdown, conectado ao sistema de tickets. O importante é que a equipe saiba qual documento prevalece e como uma mudança de requisito chega ao plano de implementação.

Comece com um CLAUDE.md ou arquivo equivalente. Inclua comandos de instalação, build, testes, lint, estrutura de diretórios, convenções e armadilhas conhecidas. Evite transformar o documento em um manual enorme. Contexto curto, atualizado e revisado costuma ser mais útil que uma enciclopédia esquecida.

Faça o agente executar os mesmos comandos usados no CI. Inclua testes relevantes, verificações de formato, análise estática e validações específicas do domínio. Em dados, isso pode incluir testes de esquema, volume, frescor e distribuição. O objetivo é permitir que o agente encontre problemas antes de abrir o pull request.

Use um agente para revisar pull requests contra uma política escrita. Comece em modo informativo. Compare os achados com revisões humanas e ajuste a política. Só depois transforme verificações maduras em gates obrigatórios. A equipe precisa calibrar falsos positivos antes de bloquear todo o fluxo.

Acompanhe tempo de ciclo, mudanças entregues, taxa de retrabalho, regressões em produção, tempo de revisão, cobertura e resultado das avaliações, além de incidentes de segurança. Uma velocidade maior com mais rollback não representa melhora. O indicador precisa capturar o custo da entrega completa.

Inclua alertas, incidentes e desvios no fluxo de intenção. Um problema recorrente pode gerar um novo intent.md, com impacto, evidências e critérios de correção. A equipe passa a aprender com o sistema em funcionamento, em vez de tratar produção como uma etapa separada.

Começar pequeno não significa começar de forma improvisada. Significa limitar o raio de ação para aprender com segurança. Depois, amplie apenas quando os resultados mostrarem qualidade estável e a revisão humana continuar acompanhando o volume. Se o agente produz mais mudanças do que o time consegue entender, a autonomia já passou do ponto.

O efeito mais plausível é deslocar o valor do trabalho, não eliminar a necessidade de engenharia. Tarefas táticas, repetitivas e verificáveis podem ser delegadas. Decisões sobre arquitetura, contexto organizacional, risco, produto e responsabilidade continuam exigindo pessoas que entendam as consequências da mudança.

A análise da Exame sobre Andrej Karpathy relata que ele passou de escrever cerca de 80% do código manualmente para revisar uma proporção semelhante produzida por modelos. O relato indica uma mudança de fluxo individual, não uma previsão de que todas as equipes terão o mesmo resultado.

A divisão mais útil não é entre tarefas “de programador” e “de IA”. É entre tarefas com critérios claros de verificação e decisões que dependem de contexto ou responsabilidade. Gerar um teste para uma função conhecida é diferente de decidir se uma regra de crédito deve mudar. Atualizar documentação é diferente de autorizar uma migração irreversível.

Agentes também não eliminam a necessidade de revisar código. Eles podem produzir uma solução que compila, passa por testes superficiais e ainda assim viola uma regra de negócio. Podem escolher uma dependência inadequada, expor dados em logs ou aumentar a conta de infraestrutura. A supervisão muda de linha a linha para intenção, risco e evidência, mas não desaparece.

No mercado, a pressão deve favorecer profissionais capazes de trabalhar com sistemas de IA sem abandonar fundamentos. Saber investigar uma falha, ler uma arquitetura, entender dados e formular testes continua valioso. Quem apenas aceita saídas pode entregar mais rápido por algum tempo, até encontrar um problema que não sabe diagnosticar.

A pergunta prática para cada função é outra: quais decisões não podem ser terceirizadas? A resposta define políticas, permissões e gates. O restante pode ser candidato a automação progressiva, desde que exista uma maneira confiável de avaliar o resultado e recuperar o controle.

AI-native SDLC é um ciclo de vida de desenvolvimento de software em que agentes participam de Plan, Design, Build, Test, Deploy e Maintain. A intenção, a especificação, o plano, os testes e as aprovações ficam registrados em artefatos versionados. Pessoas continuam definindo objetivos, limites e decisões de maior risco.

Copilot e chatbots podem acelerar uma tarefa local, como sugerir código ou explicar um erro. O AI-native SDLC reorganiza o fluxo completo. Ele conecta intenção, contexto do repositório, plano, implementação, testes, revisão e monitoramento. A ferramenta pode mudar, mas os princípios de feedback, avaliação e governança permanecem.

intent.md registra o problema e o resultado esperado. spec.md reúne requisitos e desenho. plan.md descreve a implementação. CLAUDE.md preserva contexto operacional. REVIEW.md define verificações e políticas. O formato não é obrigatório. O valor está em tornar decisões legíveis, versionadas e conectadas ao código.

Mudanças em autenticação, autorização, dados pessoais, pagamentos, migrações, infraestrutura, modelos de decisão e sistemas regulados exigem revisão humana explícita. O Microsoft Foundry recomenda combinar versionamento, tracing, avaliações, monitoramento, identidade e permissões. Testes aprovados não substituem responsabilidade.

Escolha um gargalo repetitivo, registre a linha de base e crie um arquivo de contexto no repositório. Automatize testes e lint, use um agente para propor pull requests e mantenha a aprovação humana. Depois de medir retrabalho, regressões e tempo de revisão, amplie apenas se a qualidade se mantiver.

O ganho do AI-native SDLC não está apenas em escrever mais código. Ele aparece quando a equipe reduz handoffs, preserva contexto, encurta feedback loops e transforma controles em ações executáveis. Pessoas definem intenção e limites. Agentes executam e verificam partes do trabalho. Sistemas registram evidências. Produção alimenta a próxima iteração.

O playbook da Anthropic é uma referência útil porque traduz essa mudança em arquivos, gates e práticas operacionais. Ele não deve ser tratado como receita universal. Uma equipe de dados, um produto financeiro e uma aplicação interna terão dependências e riscos diferentes.

A decisão mais prática é escolher um único gargalo. Pode ser o tempo para entender código legado, a demora na revisão, a falta de testes ou a documentação desatualizada. Crie um experimento com métrica, limite de permissão e critério de saída. Amplie somente depois de comprovar qualidade.

Para continuar acompanhando aplicações de IA, dados e engenharia no trabalho real, inscreva-se na newsletter do Data Hackers. O próximo passo não é automatizar tudo. É construir um loop em que cada ganho de velocidade venha acompanhado de contexto, evidência e responsabilidade.