Kanban: limite de WIP é o freio que o time de agentes perdeu

Todo time que adotou agentes de código sentiu a mesma euforia inicial: dá para começar tudo. Uma frente de OAuth aqui, um refactor ali, três protótipos em paralelo, tudo disparado em minutos. Semanas depois vem a resaca: muita coisa começada, pouca coisa em produção, uma fila de revisão que não anda e a sensação estranha de estar mais rápido e entregando menos. O método que descreve esse problema com precisão tem mais de uma década e não foi feito para IA. É o Kanban, e a peça que falta ao time de agentes é justamente a que ele mais defende: o limite de trabalho em progresso.

O que o Kanban realmente é

O Kanban aplicado a trabalho de conhecimento foi sistematizado por David J. Anderson no fim dos anos 2000, inspirado nos sistemas de produção puxada da Toyota. Muita gente reduz o método a um quadro com as colunas A Fazer, Fazendo e Feito. Esse quadro é a parte visível, mas não é o método. Um quadro sem regra é só uma lista de tarefas mais bonita.

O coração do Kanban são práticas que mudam o comportamento do time. Tornar o trabalho visível, para que todos vejam o que está em andamento. Limitar o trabalho em progresso, combinando um teto explícito de itens simultâneos. Gerir o fluxo, olhando para como o trabalho se move e onde ele trava. Tornar as políticas explícitas, escrevendo o que significa um item estar pronto para avançar. E criar ciclos de feedback para melhorar aos poucos, sem revolução. A prática que faz o resto funcionar é o limite de WIP.

Por que fazer menos ao mesmo tempo entrega mais

A ideia soa errada na primeira vez: como travar quantas coisas o time faz em paralelo pode acelerar a entrega? A resposta é matemática de fila. Quanto mais itens abertos ao mesmo tempo, mais cada um passa esperando, por revisão, por integração, por uma decisão, por contexto de quem parou para olhar outra coisa. O trabalho não flui, ele se acumula em estados intermediários. O resultado é um monte de coisa quase pronta e nada terminado.

Limitar o WIP inverte o incentivo. Se só três itens podem estar em andamento, o time é forçado a terminar um antes de puxar o próximo. A pergunta na reunião deixa de ser "o que mais podemos começar?" e vira "o que precisamos terminar para liberar espaço?". A entrega fica mais rápida e, o que importa tanto quanto, mais previsível.

Começar trabalho não é progresso. Terminar trabalho é progresso. O limite de WIP é o que obriga o time a lembrar da diferença.

O que muda na era dos agentes

Aqui está por que esse método de mais de dez anos ficou urgente de novo. Durante décadas, o gargalo do software foi produzir: escrever o código custava caro e demorava. Os agentes derrubaram esse custo. Como já tratamos ao falar que escrever código ficou barato, o trabalho não sumiu, mudou de lugar. O gargalo agora é revisar, integrar e entender.

E é exatamente aí que abrir frentes sem limite faz o maior estrago. Quando um desenvolvedor com agentes dispara dez tarefas em paralelo, ele não aliviou o gargalo, ele entupiu a etapa que virou escassa. Cada uma das dez frentes vai precisar de revisão humana, de integração e de alguém que entenda como aquilo encaixa no todo. Sem limite de WIP, o time gera código na velocidade da máquina e revisa na velocidade do humano, e a distância entre as duas vira uma fila invisível de risco.

Esse ponto se encaixa direto no alerta de Armin Ronacher sobre a torre de Babel dos agentes: quando cada um constrói em paralelo sem coordenar, o entendimento compartilhado do sistema se dissolve sem que nada quebre na hora. O limite de WIP é um antídoto concreto para isso. Menos frentes abertas ao mesmo tempo significa mais chance de o time acompanhar, revisar e manter a linguagem comum viva. O freio de mão que a facilidade de gerar removeu, o Kanban devolve.

Como aplicar no time de IA, na prática

Comece tornando o trabalho de agente visível no mesmo quadro do resto. Tarefa disparada para um agente é trabalho em progresso, não é "de graça" só porque a máquina faz. Se ela não aparece no quadro, o WIP real do time é maior do que ele pensa.

Defina um limite de WIP por pessoa e por etapa, e trave especialmente a coluna de revisão, que é o novo gargalo. Uma regra simples e desconfortável ajuda: ninguém puxa uma tarefa nova enquanto tiver algo seu parado esperando revisão. Isso empurra o time a fechar antes de abrir.

Escreva as políticas explícitas do que significa pronto. Numa era em que o agente gera explicação sob demanda, é fácil confundir "compila e passa nos testes" com "entendido e integrado". Definir o critério de pronto, incluindo revisão humana e verificação, é o que impede a fila de quase-prontos. Isso conversa com a disciplina de cortar em fatias finas do Story Mapping: fatia pequena, terminada de ponta a ponta, flui melhor que dez pedaços grandes abertos.

Meça o tempo de ciclo, não o volume de partidas. A métrica que interessa é quanto tempo um item leva de começar a estar em produção de verdade. Isso complementa as métricas no estilo DORA aplicadas à IA: fluxo e estabilidade valem mais que contagem de features iniciadas. E amarra com o ciclo do Lean Startup: terminar rápido é o que permite medir e aprender rápido, enquanto uma pilha de trabalho aberto só adia o aprendizado.

O Kanban não promete fazer o time produzir mais código. Na era dos agentes, produzir código deixou de ser o problema. Ele promete algo mais valioso: fazer o trabalho fluir até o fim, com o time ainda entendendo o que construiu. Num mundo onde a máquina deixou fácil começar tudo, a disciplina de limitar o que está em andamento virou uma das poucas vantagens competitivas que sobraram.

Se o seu time começou a abrir frentes demais com agentes e nada mais chega ao fim, fala com a gente no WhatsApp.