Como criar linha de base antes de adotar IA

Uma linha de base de produtividade com inteligência artificial serve para registrar como o trabalho acontece antes da mudança. Ela não prova que a IA vai funcionar. Ela cria comparação. Antes de liberar uma ferramenta, um copiloto ou um agente no fluxo de desenvolvimento, a equipe precisa registrar o trabalho atual de forma comparável. Sem isso, qualquer melhora percebida pode ser ganho real, ruído, troca de risco ou retrabalho deslocado.

Por que medir depois não responde o que mudou

A cena é comum. A equipe começa a usar IA para escrever testes, gerar trechos de código, resumir issues ou propor correções. Algumas pessoas dizem que estão mais rápidas. Outras percebem revisões mais longas, dúvidas sobre aceite ou defeitos que escaparam. A liderança pergunta: melhorou?

Se ninguém registrou o estado anterior, a resposta vira opinião organizada em reunião.

Uma linha de base antes da IA é o retrato comparável do trabalho antes da intervenção. Ela precisa mostrar o tipo de tarefa, a condição de execução, a evidência de conclusão e os sinais de qualidade que serão observados depois. O objetivo não é congelar a equipe em um processo antigo. É impedir que a comparação misture coisas diferentes.

Medir só depois da adoção costuma criar três confusões:

• A equipe compara tarefas de complexidade diferente como se fossem equivalentes.
• O tempo economizado na implementação reaparece em revisão, teste ou correção manual.
• A ferramenta declara uma tarefa concluída, mas o resultado ainda não foi verificado no ambiente real.

A linha de base reduz essa ambiguidade. Ela não elimina julgamento. Pelo contrário, dá ao julgamento humano uma base melhor.

Esse cuidado conversa com uma decisão maior de qualidade. No guia Qualidade de software com IA: testes, avaliação e responsabilidade, a pergunta central é como manter responsabilidade quando sistemas passam a gerar, sugerir ou executar partes do trabalho. Aqui, o foco é mais estreito: como comparar antes e depois sem se iludir.

Variáveis mínimas da comparação antes da IA

Uma linha de base de produtividade com IA não precisa virar um inventário exaustivo da engenharia. Se a coleta for pesada demais, ela atrapalha o próprio fluxo que deveria observar. O melhor ponto de partida é registrar apenas o que será comparado depois.

O conjunto mínimo deve incluir:

• Tipo de tarefa, como correção de bug, ajuste de interface, criação de teste, refatoração pequena ou melhoria de endpoint.
• Entrada da tarefa, como issue, especificação, bug report, pull request anterior ou alerta operacional.
• Saída esperada, como código revisado, teste passando, comportamento aceito ou documentação atualizada.
• Complexidade aproximada, descrita por critérios simples usados pela própria equipe.
• Pessoas envolvidas, principalmente quem executa, revisa e valida.
• Tempo de execução com contexto, separando execução, espera por revisão, interrupções relevantes e retrabalho identificado.
• Sinais de qualidade, incluindo revisões, testes executados, defeitos encontrados, regressões e correções manuais posteriores.
• Critério de conclusão verificável, como teste automatizado passando, aceite registrado ou mudança revisada.

O ponto mais sensível é separar tempo bruto de tempo útil para decisão. Uma tarefa pode parecer rápida porque a implementação foi acelerada, mas exigir mais perguntas na revisão. Outra pode parecer lenta porque ficou parada aguardando validação, não porque a execução técnica foi difícil.

A atualização da METR de fevereiro de 2026 é uma referência útil para cautela, sem extrapolar seus achados. A organização tratou novos dados como sinal pouco confiável sobre o efeito atual da IA na produtividade e apontou dificuldades como seleção de participantes e tarefas, além da medição de tempo com agentes concorrentes. Para uma liderança, a lição aplicável é simples: a forma de escolher tarefas e medir tempo pode distorcer a leitura.

Como escolher tarefas comparáveis sem viciar a leitura

A escolha das tarefas define a honestidade da comparação. Se a equipe seleciona apenas atividades em que a IA tende a brilhar, o piloto nasce otimista demais. Se escolhe apenas exceções complexas, urgentes ou mal especificadas, nasce pessimista demais.

A primeira etapa não é formular uma hipótese. É descobrir padrões de trabalho.

Descoberta significa observar quais tarefas aparecem com frequência, quais têm entrada minimamente parecida e quais geram evidência clara de conclusão. Só depois vem a hipótese, por exemplo: a IA pode reduzir esforço de implementação em correções repetitivas sem aumentar retrabalho de revisão.

Tarefas boas para a linha de base costumam ter algumas características:

• São recorrentes no fluxo da equipe.
• Têm entrada e saída relativamente reconhecíveis.
• Não dependem de uma pessoa única com conhecimento tácito excessivo.
• Permitem verificar resultado por revisão, teste, aceite ou observação do comportamento.
• Representam trabalho real, não uma demonstração isolada.

Tarefas ruins para começar são as que mudam de natureza a cada ocorrência, dependem de decisão estratégica, exigem negociação com várias áreas ou têm qualidade difícil de observar no curto prazo. Elas podem ser avaliadas depois, mas tendem a gerar ruído na primeira comparação.

Depois de registrar o estado anterior, o próximo passo é decidir como medir a produtividade de desenvolvedores com IA. Medir produtividade é uma discussão mais ampla. Criar a linha de base é o passo anterior: escolher o que será comparável antes que a ferramenta altere o comportamento da equipe.

Qualidade observável além da velocidade

A adoção de IA em desenvolvimento de software costuma ser vendida pela sensação de velocidade. A liderança, porém, precisa perguntar onde o esforço foi parar.

Se uma ferramenta gera código mais rápido, mas aumenta o tempo de revisão, cria testes frágeis ou transfere correções para depois do deploy, a produtividade aparente não basta. A linha de base precisa registrar qualidade observável antes da mudança.

Qualidade observável não significa medir tudo. Significa escolher sinais que permitam comparar efeitos laterais. Alguns exemplos:

• Quantidade e tipo de comentários em revisão de código.
• Testes executados antes da conclusão.
• Defeitos encontrados durante revisão ou validação.
• Reabertura de tarefas por comportamento incorreto.
• Correções manuais feitas depois da sugestão ou geração automática.
• Dúvidas recorrentes sobre critério de aceite.

O DORA recomenda testes ao longo do desenvolvimento, combinando automação e atividades manuais, como exploração e usabilidade. Também recomenda manter e revisar as suítes de teste, em vez de tratar qualidade como etapa posterior ao desenvolvimento. Para uma linha de base, isso reforça que qualidade não deve aparecer apenas no fim, quando o custo de entender o que mudou já aumentou.

Um exemplo fictício ajuda. Uma equipe decide observar correções de bugs de baixa e média complexidade antes de permitir IA na geração de patches. Durante algumas semanas, registra tempo de diagnóstico, tempo de implementação, revisões, testes executados, defeitos reabertos e correções manuais após revisão. No piloto, a comparação só considera bugs do mesmo tipo e mantém o mesmo critério de pronto.

Nada nesse exemplo afirma que a IA melhorou ou piorou o fluxo. O valor está em deixar a hipótese mensurável. Se a implementação parecer mais rápida, a equipe terá como verificar se o ganho veio acompanhado de mais revisão, mais retrabalho ou qualidade estável.

Como comparar trabalho humano, ferramenta assistiva e agente

Nem toda adoção de IA tem o mesmo risco. Colocar todas as ferramentas na mesma comparação é uma forma rápida de perder clareza.

Há pelo menos três modos diferentes de uso:

• IA como sugestão pontual, quando a pessoa consulta a ferramenta e decide se usa ou descarta a resposta.
• IA como copiloto de execução, quando a ferramenta gera artefatos relevantes, como código, testes, documentação ou consultas.
• Agente, quando o sistema executa uma sequência de ações e pode alterar arquivos, acionar ferramentas ou interagir com o ambiente.

A linha de base deve registrar o grau de autonomia porque o critério de confiança muda. Em uma sugestão pontual, a pessoa continua sendo a executora direta. Em um agente, a avaliação precisa confirmar o resultado no ambiente, não apenas a narrativa da ferramenta.

A Anthropic distingue a trajetória de execução do agente do resultado efetivo no ambiente. Uma mensagem dizendo que a tarefa terminou não basta para comprovar que o objetivo foi atingido. A avaliação usa entradas, critérios de sucesso e verificadores, e pode exigir várias tentativas.

Para uma liderança de engenharia, isso muda o registro da linha de base. Não basta anotar que o agente respondeu bem. É preciso registrar qual evidência confirma a conclusão: teste passando, pull request revisado, arquivo alterado corretamente, comportamento validado ou aceite registrado.

Quando a IA aciona mudanças reais, a comparação deve separar disponibilizar código de ativar funcionalidade. O capítulo de canary releases do Google SRE trata da avaliação de uma mudança em uma parcela do tráfego antes de ampliar exposição e distingue disponibilizar código de ativar funcionalidades por configuração. Essa separação é útil quando a equipe quer observar uma mudança antes de ampliar seu impacto.

Critérios de pronto para iniciar o piloto

Use este checklist como critério de pronto ou não pronto para iniciar um piloto com IA em um fluxo de desenvolvimento.

Tarefas comparáveis

Pronto quando há pelo menos alguns tipos de tarefa recorrente descritos com entrada, saída esperada, complexidade aproximada e responsável pela validação.

Se faltar, a comparação depois da IA pode misturar tarefas fáceis, urgentes ou incomparáveis.

Tempo medido com contexto

Pronto quando o registro separa tempo de execução, espera por revisão, interrupções relevantes e retrabalho identificado.

Se faltar, a equipe pode atribuir ganho ou perda à IA quando a variação veio do fluxo de trabalho.

Qualidade observável

Pronto quando a linha de base inclui revisão de código, testes executados, defeitos encontrados, regressões e correções manuais posteriores.

Se faltar, a adoção pode parecer mais rápida enquanto transfere custo para revisão, suporte ou correção.

Critério de conclusão

Pronto quando cada tarefa tem uma evidência verificável de conclusão no ambiente de trabalho, como teste passando, aceite registrado ou alteração revisada.

Se faltar, uma declaração de conclusão pela ferramenta pode ser confundida com resultado efetivo.

Grau de autonomia da IA

Pronto quando o registro informa se a IA apenas sugeriu, gerou artefatos, executou etapas ou acionou mudanças no ambiente.

Se faltar, ferramentas com níveis de risco diferentes entram na mesma comparação.

Condições estáveis de comparação

Pronto quando a equipe identifica mudanças simultâneas relevantes, como troca de processo, mudança de equipe, novo padrão de testes ou pressão excepcional de prazo.

Se faltar, o resultado do piloto pode refletir mudanças organizacionais, não a adoção de IA.

Decisão antes da coleta

Pronto quando está definido o que acontecerá se o resultado for positivo, inconclusivo ou negativo: ampliar, repetir, restringir ou interromper.

Se faltar, a medição vira argumento retrospectivo para uma decisão já tomada.

Esse último item é desconfortável porque obriga a liderança a declarar antes o que aceitará como evidência. Mas é justamente aí que a linha de base deixa de ser burocracia e passa a ser governança prática.

Quando a linha de base ainda não é confiável para decidir escala

Uma linha de base melhora a comparação, mas não transforma um piloto pequeno em verdade geral. Ela ajuda a decidir o próximo passo com menos ruído.

Há situações em que a melhor decisão é não escalar ainda:

• A amostra observada é pequena demais para sustentar uma mudança ampla.
• As tarefas foram escolhidas por conveniência e não representam o fluxo real.
• A equipe mudou processo, ferramenta, pessoas e meta ao mesmo tempo.
• O tempo foi medido sem separar espera, interrupção e retrabalho.
• A qualidade foi avaliada apenas por percepção.
• O agente declarou conclusão sem verificação externa do resultado.
• O piloto teve resultado positivo em velocidade, mas inconclusivo em qualidade.

Nesses casos, a liderança não precisa rejeitar IA. Pode restringir o uso, repetir a comparação, escolher outro tipo de tarefa ou redesenhar a avaliação. A decisão útil é saber que tipo de evidência falta para ampliar, restringir, repetir ou interromper o uso.

Uma equipe pode permitir uso assistivo em tarefas de baixo risco e manter agentes restritos a ambientes controlados. Pode liberar geração de testes, mas exigir revisão humana explícita antes de aceitar mudanças em código de produção.

Antes de adotar IA em um fluxo de desenvolvimento, a pergunta não é apenas qual ferramenta parece melhor. É que evidência a liderança aceitará para ampliar, restringir, repetir ou interromper o uso. Se tarefas comparáveis, tempo com contexto, qualidade observável, grau de autonomia e evidência de conclusão ainda não existem, a próxima decisão é criar a linha de base e rodar uma comparação limitada.

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.

Leituras para continuar

• Como testar cenários de falha em produtos inteligentes
• Como decidir se uma funcionalidade de IA pode ir para produção

Fontes

• DORA: automação de testes
• METR: limites da medição de produtividade
• Anthropic: avaliações de agentes
• Google SRE: lançamentos graduais