Esses dias a timeline do YouTube me empurrou um vídeo sobre ADLC, sigla pra Agentic Development Lifecycle. Cliquei sem muita expectativa e passei os minutos seguintes reconhecendo, num conceito que eu não tinha ouvido falar, a forma como já venho trabalhando há um bom tempo. Meu dia a dia hoje é basicamente orquestrar vários agentes de código ao mesmo tempo, em projetos diferentes, enquanto decido o que importa e pra onde cada coisa caminha. O que o vídeo fez foi me dar um nome pra um formato que eu já tinha montado naturalmente, e isso que quero escrever sobre o assunto neste artigo.
Agentes executam, humanos governam
A ideia do ADLC, do jeito que a Arthur.ai e a IBM vêm descrevendo, é uma releitura do ciclo de desenvolvimento tradicional pra um mundo em que o software deixou de ser totalmente previsível. Os agentes executam, os humanos governam, e o pipeline deixa de ser uma linha reta pra virar um ciclo que se repete. No modelo antigo a gente assume que o comportamento do sistema está especificado de antemão e validado antes de entrar no ar (você pode sentir que isso é o que existe hoje, mas não, isso é mais antigo. Apenas algumas pessoas que "abriram os olhos agora" que acham que isso é novidade). Sistemas que dependem de agentes não cabem nessa premissa, porque eles raciocinam e agem em situações que ninguém previu uma a uma. O peso do trabalho então sai de entregar de uma só vez e passa pra um movimento contínuo de observar o que o agente fez e então corrigir o rumo. O humano deixa de escrever cada etapa e passa a definir a intenção e os limites dentro dos quais o agente atua.
Coletei as ideias e resumi numa tabela como eu via o desenvolvimento antes e como passei a enxergar agora:
| SDLC, como a gente via | ADLC, como vejo hoje | |
|---|---|---|
| O que se define antes | Todo o comportamento, no detalhe | A intenção e os limites; o resto emerge |
| Quando se valida | Antes de entregar, de uma vez | O tempo todo, observando o agente agir |
| O papel do humano | Escrever cada passo | Dar direção e decidir o que entra |
| O papel da máquina | Executar o que mandei | Decidir o "como" dentro do que pedi |
| O gargalo real | Escrever o código | Governar e decidir |
| Formato do processo | Uma fila de etapas | Um loop que observa e corrige |
| Pra crescer | Mais gente escrevendo | Mais agentes, e melhor governança |
Concordo com a premissa inteira, e não é por "modinha" não. Quem já tentou tocar mais de um agente ao mesmo tempo percebe rápido que o gargalo deixa de ser escrever código e passa a ser dar direção e tomar decisão. O dia vira um ciclo de delegar trabalho e revisar o que volta, repetido em paralelo várias vezes. É exatamente o que o ADLC descreve, e por isso ele me soou tão familiar logo nos primeiros minutos.
PS: Gosto de colocar sempre um paralelo com o mundo real, em meus treinamentos percebo uma facilidade de assimilação pelos alunos. E neste aspecto, dependendo da posição que você trabalhe ou já trabalhou, como um Techlead por exemplo, você pode se ver como antigamente você liderava sua equipe de humanos, agora você lidera uma equipe de agentes.
Cheguei nisso sem saber o nome
Quando voltei ao conceito e li com calma, vi que tinha chegado sozinho a vários dos princípios dele sem nunca ter lido nada a respeito. Tratar quem governa e quem executa como duas camadas separadas, por exemplo, foi uma decisão que tomei porque misturar as duas coisas simplesmente não funcionava quando o volume cresceu. As transições do meu fluxo de trabalho disparam tarefas de verdade em vez de serem caixinhas pra marcar, e as etapas que comprometem esforço só acontecem depois que eu aprovo. Nada disso foi adivinhação, mas tomou forma de tanto procurar os formatos que me ajudavam a aguentar o tranco do dia a dia.
Faço questão de marcar essa diferença porque é fácil escorregar pra um tom de profecia que eu não mereço. O que aconteceu foi uma convergência que me fez chegar aos mesmos lugares que o ADLC está formalizando agora, só que pela prática. O que o conceito me trouxe de novo foi o vocabulário pra nomear o que eu já fazia, e a tranquilidade de saber que aquilo não era mania minha, mas um fundamento que outras pessoas estavam reconhecendo na mesma época.
O gargalo que ninguém olha
É aqui que eu paro de só concordar e começo a opinar. O ADLC fala em humanos governando, e quase todo material que encontrei trata essa governança como uma atividade manual, em que a pessoa olha um painel, lê o estado, aprova e corrige por conta própria. Como ponto de partida faz todo sentido, mas tenho sérias dúvidas de que isso se sustente conforme as coisas crescem. Existe uma ironia no modelo: ao colocar os agentes pra produzir, ele resolve o gargalo da execução e empurra esse mesmo gargalo pra cima da governança. Quanto mais agentes você consegue colocar pra trabalhar, mais decisão, triagem e contexto recaem sobre uma cabeça só. Governar dez agentes na mão é um trabalho de tempo integral, e cedo ou tarde vira o teto de tudo.
Minha aposta é que o próximo passo do ADLC é tornar a própria governança assistida por um agente. Não estou falando de mais um executor, e sim de um copiloto que enxerga o conjunto inteiro e ajuda a pensar e a organizar o trabalho na altura do sistema, em vez de produzir a entrega em si. Alguém pra raciocinar junto comigo sobre o todo, não sobre a tarefa da vez. Isso só funciona com uma condição da qual não dá pra abrir mão, que é uma fronteira de autoridade bem desenhada. Um copiloto que possa agir livremente deixa de ser ajuda e vira apenas mais um agente solto, e aí você perdeu justamente a parte em que o humano governa (do conceito do ADLC). A linha que me parece certa funciona em camadas de permissão: ele lê tudo e organiza o que quiser, porque isso é barato e fácil de desfazer; quando alguma ação vai disparar trabalho ou mexer no escopo, ele me propõe e espera o aval; e disparar execução sozinho é a única coisa que ele nunca pode fazer. Aprendi na prática, aliás, que essa fronteira não pode existir só como uma instrução escrita no prompt do agente, porque instrução desse tipo se contorna com jeitinho. Ela tem que estar garantida na camada de baixo, no próprio sistema, longe do alcance do agente.
E aqui vai a parte mais opinativa do que eu penso. A corrida hoje é quase toda por modelos melhores e por fazer o agente escrever mais código sozinho, e eu acho que boa parte da indústria está otimizando o lado errado do problema. O modelo já executa bem o suficiente pra maior parte do que eu preciso no dia a dia. O que não acompanha é a minha capacidade de governar o que sai dele quando são muitos agentes trabalhando ao mesmo tempo. A próxima vantagem de verdade não vai vir de um modelo dez por cento melhor, vai vir de ferramentas que me deixem governar dez agentes com a mesma tranquilidade com que eu governo um, e vejo poucos olhando pra esse lado ainda.
Tem muita gente preocupada se a IA vai substituir o programador. Da trincheira onde eu estou, vejo o movimento oposto acontecendo. O programador está virando uma espécie de maestro, e a habilidade que passa a valer é dar direção, cortar cedo o que não presta e manter várias frentes coerentes ao mesmo tempo. Digitar rápido importa cada vez menos. Isso é governança no fim das contas, e é justamente a habilidade que as ferramentas mal começaram a apoiar.
Onde o agente para e eu começo
Pode soar que governança assistida seja um jeito disfarçado de tirar o humano do meio, mas a minha intenção é exatamente a oposta. Humanos governando é uma necessidade de operação antes de ser uma boa frase. Por melhor que os agentes se auto-verifiquem, e eles fazem isso muito melhor do que eu esperava, existe um limite que eles não cruzam sozinhos. Já vi mais de uma vez um trabalho passar por revisão e por baterias inteiras de teste automatizado e só revelar o problema quando eu mesmo rodei o sistema de ponta a ponta, com a cabeça de quem vai usar aquilo de verdade. Existe uma classe de erro que só aparece quando alguém exercita o todo com intenção real, e nenhuma suíte de testes substitui esse momento.
É por isso que a validação humana é onde o ciclo realmente fecha, e a governança assistida serve justamente pra me dar mais alcance nesse ponto. Com ela eu consigo governar mais coisa, e governar melhor, sem perder a palavra final. O agente me ajuda a enxergar e a deixar tudo preparado, mas a autoria da decisão continua sendo minha, e é assim que eu quero que continue.
Tem uma lição sobre convergência que eu levo dessa história. Quando você chega sozinho aos mesmos padrões que um framework está apenas começando a nomear, isso diz algo bom sobre o framework e algo bom sobre as suas escolhas, que pegaram fundamento e não moda. O nome ter chegado depois do trabalho é um problema bom de se ter.
Bottom line. Orquestrar agentes só vai escalar quando a própria governança tiver a ajuda de um agente, com fronteira clara e a decisão final na mão de quem assina. Pra mim isso já passou de teoria faz tempo. Venho juntando esses aprendizados num app meu, feito sob medida pro meu jeito de organizar o trabalho e de tocar os agentes do dia a dia. Ainda está tomando forma. Quando estiver redondo, compartilho por aqui.