PulseFlow Tecnologia
← Insights
·7 min de leitura·framework-playbook·readiness·sdlc·governanca
PulseFlow Tecnologia

Framework de readiness para Agentic AI no SDLC

Antes de escalar agentes de código para todo o ciclo de desenvolvimento, vale um assessment honesto: em quais das dez dimensões do SDLC o time já está pronto, e em quais ainda não. Três fontes documentam, cada uma, uma peça diferente desse readiness - requisitos, arquitetura/código, e governança.

Requisitos: specs, não prompts soltos

O primeiro teste de readiness é simples: requisitos chegam ao agente como especificação estruturada - jornada do usuário, critério de sucesso, plano técnico - ou como prompt improvisado? O GitHub documenta essa distinção como a diferença entre spec-driven development e vibe coding: sem spec, "clareza sobre como deve interagir com sistemas existentes" só aparece depois que o código já foi escrito, quando corrigir já é caro.

Arquitetura e código: legibilidade para agente, não só para humano

O experimento de harness engineering da OpenAI define o segundo teste: o repositório é "legível" o suficiente para que um agente entenda o domínio de negócio a partir do próprio código, sem depender de contexto tácito em conversas que ele nunca vê? Times prontos documentam decisões de arquitetura dentro do repositório; times não prontos ainda mantêm conhecimento crítico espalhado em Slack, reuniões, ou na cabeça de uma pessoa só.

Testes: parte da execução do agente, não etapa manual posterior

Um time pronto trata testes como parte do próprio ciclo de execução do agente - rodando antes de qualquer PR ser considerado pronto para revisão, não como checagem manual que um humano faz depois. Isso é readiness de processo, não de ferramenta: exige que a suíte de testes já exista e seja confiável o suficiente para o agente rodar contra ela sem supervisão constante.

Segurança, DevOps e observabilidade: a mesma camada que Microsoft descreve

A tese central da Microsoft - "AI alone won't change your business. The system running it will" - define o padrão para essas três dimensões: segurança nativa (não adicionada depois), DevOps que trata deploy de agente como parte do pipeline normal, e observabilidade que cobre o ciclo completo - "source, test, deploy, observe, and improve". Um time pronto tem essas três peças já funcionando para código escrito por humano; escalar para agente é extensão, não construção do zero.

Dados: governança que já existe, não que será criada para o agente

Dados que um agente vai acessar precisam de classificação, escopo e política de retenção que já deveriam existir independente de agente algum - se essa governança não existe para acesso humano, não vai aparecer magicamente quando um agente entrar no processo.

Governança e métricas: donos definidos, não responsabilidade difusa

O teste final de readiness: existe um dono claro para cada agente em produção, com métricas de sucesso definidas antes do deploy, não descobertas depois que algo já deu errado? Ausência de ownership claro é o sinal mais confiável de que um time ainda não está pronto, independentemente de quão sofisticada seja a tecnologia que estão usando.

As dez dimensões do assessment

  1. Requisitos - spec estruturada, não prompt solto
  2. Arquitetura - decisões documentadas no repositório, não em Slack
  3. Código - legível para agente, convenções explícitas
  4. Testes - parte da execução, não checagem manual posterior
  5. Segurança - nativa, não adicionada depois
  6. DevOps - deploy de agente no mesmo pipeline, não processo à parte
  7. Observabilidade - ciclo completo: source, test, deploy, observe, improve
  8. Dados - governança já existente, não criada especificamente para o agente
  9. Governança - dono claro por agente
  10. Métricas - sucesso definido antes do deploy, não depois

Como usar o assessment

Cada dimensão recebe uma nota independente - é comum um time estar pronto em testes e código, mas não em dados e governança. O objetivo não é uma nota única de "pronto" ou "não pronto"; é um mapa de onde investir antes de escalar, porque a dimensão mais fraca é a que vai determinar o tamanho real do incidente quando (não se) alguma coisa der errado.

Fontes