A impossibilidade de medir a produtividade da IA

Este texto é longo, desculpa. Eu já escrevi antes que costumo escrever quando estou tentando entender alguma coisa. Essa pergunta em particular me incomoda faz tempo, e toda vez que achei que tinha respondido, descobri outra coisa errada na resposta.

Na Flowstate, nos perguntam o tempo todo como medir o retorno do investimento em IA. Às vezes a pessoa quer saber se os times dela estão mais produtivos. Às vezes só precisa de algo crível para mostrar ao conselho quando ele perguntar da conta. Justo.

Meu interesse vai além de ter uma empresa que precisa responder a essa pergunta. Eu acredito que a IA pode tornar as pessoas muito mais capazes, e quero que seja isso que a gente construa. Que os agentes cuidem da porcaria repetitiva. Que as pessoas ganhem mais tempo para o trabalho que de fato querem fazer, inclusive coisas que antes elas não podiam bancar tentar.

Essa é boa parte da ideia por trás da Flowstate. Mas eu não posso presumir que isso está acontecendo só porque gosto da ideia.

Venho lendo a The Humanist Review, e caramba, tem escrita muito boa lá. Sério, vai dar uma olhada. O ensaio de Daron Acemoglu sobre IA e trabalho vale a leitura inteira, mas esta frase sobre o setor corporativo ficou na minha cabeça:¹

It will demand more pro-worker tools when it focuses on increasing productivity and innovation, rather than only labor cost-saving.

Acho que ele tem razão. Se eu defendo a IA só em termos dos salários que ela poderia substituir, não posso me surpreender quando a conversa vira corte de empregos. Prefiro poder explicar o que o time agora consegue fazer e antes não conseguia. Ou se eliminar algum processo chato realmente melhorou o dia de trabalho de alguém.

O problema é demonstrar isso. Alguém dizer que economiza uma hora por dia é interessante, mas eu ainda quero saber o que mudou. A pessoa produziu mais? Finalmente teve tempo de pensar direito em alguma coisa? Talvez a ferramenta tenha poupado uma hora dela e dado a outra pessoa uma hora de revisão.

Então comecei a procurar um jeito de comparar o trabalho que uma empresa entrega com o que ela gasta para entregar. De preferência algo útil entre times diferentes, seja o trabalho feito por funcionários, terceirizados, um prestador de serviço ou agentes. Eu não esperava que todo departamento tivesse a mesma ideia de sucesso. Esperava que a gente conseguisse concordar em parte da contabilidade.

Cheguei a uma abordagem que acho que vale testar, não a uma resposta que eu mandaria todo mundo adotar. Várias das minhas ideias anteriores estavam erradas. Deixei os erros úteis aqui, porque explicar por que falharam provavelmente ajuda mais do que fingir que cheguei à versão atual por previsão excepcional.

O primeiro problema é fácil de demonstrar: dê a um agente as perguntas simples de suporte, e as pessoas que ficam com as difíceis de repente parecem piores no trabalho.

Aparentemente, ajudar o time piorou tudo

Pense num time de suporte que atende 800 casos fáceis e 200 difíceis por mês. Um caso fácil exige seis minutos de atendimento humano. Um difícil exige trinta. Todos são resolvidos no mesmo padrão.

São números inventados.

Antes da IA, esse time hipotético precisava de 180 horas de atendimento para os 1.000 casos. São 5,56 casos por hora.

Agora um agente cuida de 600 dos casos fáceis. Sobram para as pessoas 200 fáceis e 200 difíceis: 120 horas para 400 casos, ou 3,33 por hora.

O painel mostra uma queda de 40% na taxa do time humano. O tempo médio de atendimento vai de 10,8 minutos para 18.

Ninguém ficou mais lento. As pessoas ficaram com os casos mais difíceis. Os fáceis diluíam a média, e agora sumiram.

A empresa continua com os 1.000 casos resolvidos e precisa de sessenta horas a menos de atendimento humano. Eu volto ao valor dessas horas daqui a pouco. Por ora, pedir que o time recupere a média antiga seria uma resposta bem idiota a uma mudança que a gente fez de propósito.

Passe os casos fáceis para um agente

i

Fáceis, pessoasDifíceis, pessoasFáceis, agente

Casos fáceis que o agente resolve por mês600 de 800

Casos por hora humana

5,56 → 3,33

Horas de atendimento humano

180 → 120

Entrega reconhecida

$7.200 → $7.200

Custo alocado ao atendimento

$7.200 → $5.280

Gasto real, folha de pagamento inalterada

$7.200 → $7.680

Os casos por hora humana caem 40%. Os mesmos 1.000 casos continuam sendo resolvidos, e sobram 60 horas de atendimento para outra coisa.

Isso aconteceu antes dos chatbots. O Remote Encoding Center do Serviço Postal dos EUA cuida das imagens de endereço que as máquinas não conseguem decifrar. Um relato de 2022 descreve máquinas pegando as imagens mais fáceis e deixando para as pessoas as que levavam mais tempo para interpretar.² O vídeo do Tom Scott no centro continua sendo um dos meus exemplos favoritos de um sistema automatizado mudando um processo de negócio, anos antes de alguém chamar aquilo de IA. A Intercom faz a mesma observação sobre a carga de casos que sobra para humanos depois da automação do suporte.³

Também existe boa pesquisa usando justamente a taxa que acabei de criticar. Em Generative AI at Work, Erik Brynjolfsson, Danielle Li e Lindsey Raymond relatam um aumento médio de 15% nos chamados resolvidos por hora. O assistente de IA deles ajudava as pessoas que respondiam aos clientes. Não assumia uma fila separada de casos fáceis. Eles também examinaram a qualidade e a experiência do trabalho.⁴

Não discordo de contar casos nesse cenário. Discordo de presumir que eles continuam comparáveis depois de mudar quais casos as pessoas recebem. “Casos por hora” pode ser útil. Mas precisa de uma descrição dos casos.

E mesmo no meu exemplo arrumadinho, um dia com menos perguntas fáceis pode ser um dia mais exigente. Nada na tabela diz se o trabalho melhorou.

O que a gente está perguntando, afinal?

Entregamos mais? Gastamos menos recursos? O trabalho produziu algo útil? As pessoas que o fizeram tiveram um dia melhor?

São perguntas diferentes. Eu fui culpado de tratar “produtividade” como se respondesse as quatro.

Contagens falam de volume. Custos dizem o que a gente colocou. Lead time diz quanto tempo alguém esperou. Receita e margem importam, mas não dizem o que aconteceu dentro de cada time. Uma pesquisa perguntando se as pessoas se sentem mais rápidas também não.

O experimento da METR com desenvolvedores, no começo de 2025, mostra esse último ponto de um jeito meio doloroso. Desenvolvedores experientes, trabalhando em repositórios open source que conheciam, levaram 19% mais tempo com as ferramentas de IA disponíveis. Depois, ainda estimaram que as ferramentas os tinham deixado 20% mais rápidos.⁵ É um resultado daqueles desenvolvedores e daquelas ferramentas, não um veredito sobre agentes de programação em 2026. A atualização da METR de fevereiro de 2026 diz que as ferramentas mais novas provavelmente ajudam mais, e explica por que efeitos de seleção dificultam estimar essa melhora.⁶

Tem, inevitavelmente, uma pesquisa da McKinsey. Nos resultados de agosto de 2026, 80% dos respondentes disseram que a IA melhorou a própria produtividade. Só 37% atribuíram a ela algum impacto no lucro da empresa.⁷ Uma lacuna útil para uma consultoria encontrar. Também são duas perguntas autodeclaradas diferentes, então não dá para subtrair um percentual do outro e declarar que o benefício que faltava foi roubado.

O framework SPACE me ajudou a pôr um limite na pergunta. Nicole Forsgren, Margaret-Anne Storey e os coautores argumentam que a produtividade de desenvolvedores não cabe em uma única métrica ou dimensão.⁸ Concordo. Uma medida de eficiência de entrega ainda pode ser útil. Ela só precisa parar de afirmar que descreve todo o resto.

Vou chamar a proposta de índice padronizado de entrega. Ele trata do trabalho entregue e dos recursos por trás dele. O resultado de negócio e a experiência de fazer o trabalho precisam das próprias evidências.

Testei os números que a gente já tinha

Cada um parecia razoável até eu dar a ele um exemplo incômodo.

As tabelas não são motivo para jogar fora todas as medidas existentes. Eu precisei de partes de várias. O que falhava sempre era a suposição de que uma só dava conta do serviço inteiro.

Testei os candidatos contra onze casos inventados, incluindo um agente pegando o trabalho fácil e um time se dividindo em dois. Minhas anotações de trabalho têm os casos, os dados fictícios e os cálculos. Trate isso como um registro de como a ideia mudou, não como onze testes provando que a versão final funciona numa empresa.

Trabalho não é um ticket

Minha primeira definição era agradavelmente arrumada: contar o trabalho que alguém pediu e aceitou.

Infelizmente, a empresa que eu tinha descrito não existia.

Na Flowstate, o nosso próprio Linear quase sempre está atrás do trabalho que de fato acontece. Não preciso de um estudo histórico sobre issue trackers para reconhecer esse problema.

Um engenheiro nota alguma coisa, conversa, corrige e cria um ticket em algum ponto do caminho. Um cliente abre uma conversa no Intercom. Chega uma fatura. Um advogado dá um parecer numa ligação. O engenheiro de plantão investiga porque manter o serviço no ar já é responsabilidade dele.

Um botão de aprovação não torna o trabalho legítimo. E quem cria o registro não é necessariamente quem precisava do trabalho.

O que eu quero contar é uma entrega ou um serviço de negócio com um propósito, um escopo e uma condição de conclusão que a gente consiga explicar. Um pedido pode estabelecer essas coisas. Um objetivo combinado, um problema de cliente ou uma responsabilidade permanente também. Um engenheiro não deveria precisar que outro departamento encomende a correção de uma vulnerabilidade para ela contar.

As definições vão variar por função. Não vejo como contornar isso.

Esses nomes não são alternativas para linhas de um banco de dados. Uma mudança integrada pode estar incompleta. Uma fatura marcada como paga pode estar errada. Um cliente em silêncio pode estar satisfeito ou furioso.

A evidência está espalhada. Um único incidente pode deixar uma conversa de suporte, uma issue de engenharia, três pull requests e um e-mail de acompanhamento. Contar seis registros não estabelece seis entregas. A mineração de processos centrada em objetos ajuda aqui porque representa eventos ligados a vários objetos de negócio.⁹ Ela ajuda a juntar os registros. Não decide quanto o incidente deve valer.

Se as empresas vão compartilhar o contexto relevante e se a IA consegue interpretá-lo com confiança são problemas à parte. Vou deixá-los fora deste texto. Para a contabilidade, suponha que a gente consiga estabelecer um relato bom o bastante do trabalho e dos custos, por revisão humana, automação ou as duas.

Ainda sobra uma pergunta difícil: dada a evidência, o que a gente conta? Evidência ausente deve deixar o trabalho em aberto, não declará-lo sem valor. Do contrário, estou construindo uma medida de quem escreve as notas de conclusão mais entusiasmadas.

Os contadores já passaram por aqui

O exemplo do suporte precisa de um jeito de distinguir seis minutos de trabalho de trinta. Essa parte, pelo menos, não é nova.

A ACCA descreve horas-padrão como uma forma de combinar produtos diferentes numa única medida de produção. Ela separa quanto foi produzido, quanto da capacidade disponível foi usada e com que eficiência.¹⁰ O ONS usa índices de atividade ponderados por custo para boa parte da produção de serviços públicos.¹¹

Estou pegando emprestada essa estrutura: contar as entregas por tipo e depois usar pesos de referência estáveis para somá-las. Isso nos dá uma escala sem exigir que todo serviço interno tenha um preço de venda.

O ONS também serve como checagem da minha ambição. Cerca de um terço da produção de serviços públicos coberta pela metodologia dele ainda usa a convenção de que insumos são iguais a resultados, o que torna a produtividade constante nessa parte.¹¹ A existência de medição ponderada por custo não significa que alguém já descobriu como medir todo serviço.

De volta ao suporte. A uma taxa de trabalho de referência de $40 por hora, uma resolução fácil carrega um peso de $4 e uma difícil, $20. Multiplique cada contagem pelo peso e some:

D = 800 × 4 + 200 × 20 = 7.200

(1)

Dá $7.200 antes do agente e $7.200 depois. O negócio recebeu as mesmas 800 resoluções fáceis e 200 difíceis. Torná-las mais baratas, 600 delas, não as faz desaparecer da produção.

Escrito de forma geral:

D_t = Σ_k n_k,t s_k,b

(2)

D é a produção entregue em dólares de custo de referência. n é a contagem de cada tipo e s é o custo de referência de ponta a ponta. t identifica o período que estamos medindo, e b identifica o período de referência. A soma percorre os tipos de trabalho.

Esses dólares não são receita nem economia. Eles nos deixam comparar quantidades de trabalho diferente usando um único conjunto declarado de pesos.

No começo tentei justificar o peso argumentando que o custo histórico era um piso para o valor. Afinal, uma empresa não pagaria quatro horas por um trabalho que vale menos de quatro horas, certo?

Uma avaliação extremamente generosa da tomada de decisão corporativa. Empresas compram o que não deviam, e investimentos sensatos podem falhar. O custo antigo diz alguma coisa sobre a produção. Não prova quanto o resultado valia.

Numa empresa de verdade, o padrão cobriria a mistura relevante de pessoas, ferramentas, agentes e serviços comprados. Onde temos estimativas críveis de esforço por função, taxas de referência fixas impedem que o mesmo trabalho ganhe um peso maior porque uma pessoa mais cara o fez. Um serviço comprado pode precisar de um preço de referência comparável.

Salários e faturas reais ficam no lado do custo. A mesma entrega com o mesmo escopo deve ter o mesmo peso de produção em Londres e em Lisboa. Trocar o fornecedor também não deve mudá-lo.

Horas-padrão funcionam onde fazem sentido. Mas um índice que cobre trabalho automatizado precisa de mais do que as horas humanas que sobram, ou os pesos podem tender a zero à medida que a automação dá certo. Custos de recursos de referência dão uma base mais ampla.

E o período de referência não precisa ser anterior à IA. Precisa ter evidência utilizável. “Antes de alguém usar o ChatGPT” não vai continuar sendo uma data útil para sempre.

Isso não é só story point em dólar?

Pode ser. Primeiro, uma correção que já vi engenheiros, com razão, ficarem irritados por precisar fazer: story points não são horas. Eles foram feitos para dimensionar o trabalho em relação a outro trabalho, por complexidade e incerteza, e é por isso que tantos times usam uma escala meio Fibonacci. Os intervalos aumentam quando a confiança cai. Converter pontos em horas nunca foi o objetivo.

O risco aqui é outro. Pegar as estimativas do time, transformá-las em dólares e chamar o resultado de objetivo seria o mesmo chute com uma embalagem financeira melhor.

O pedido de desculpas do Ron Jeffries por ter possivelmente inventado os story points é engraçado, mas não responde a essa objeção.¹² Gergely Orosz descreve um desenvolvedor inflando estimativas quando o time passou a tratar os pontos da sprint como teste de sucesso.¹³ Um sistema de custo de referência oferece a mesma tentação. Ponha um peso maior no trabalho e a nota melhora.

O que eu quero é um padrão para uma classe de trabalho entregue, não uma estimativa em andamento de quão difícil parece esta tentativa específica. Uma estimativa de planejamento pode subir quando a gente encontra um problema. O peso da produção não deveria subir só porque a gente levou mais tempo. Se o escopo mudou, a gente precisa dizer o que mudou.

Eu construiria o padrão a partir de exemplos revisados de trabalho comparável e o testaria em outros exemplos. Fixe os pesos para a comparação. Registre as mudanças para que nem o time nem o gerente consigam melhorar um resultado reportado inflando-os depois.

Ainda há julgamento nisso. Quais trabalhos pertencem ao mesmo grupo? O caso caro é outro tipo de trabalho ou uma tentativa cara da mesma coisa? Um revisor precisa poder questionar tanto a categoria quanto o peso.

Até escolher a média importa. A mediana descreve um caso típico. Multiplicada pelo volume, ela em geral não reproduz o uso total de recursos numa carga de trabalho com cauda longa. Para um peso esperado de custo de recursos, eu normalmente começaria com a média de uma classe bem definida e mostraria a dispersão. Não escolheria a estatística que deixasse o índice mais bonito.

A IA poderia ajudar a sugerir pesos. O trabalho da Anthropic sobre estimar a duração de tarefas encontrou informação útil de ranqueamento, mas o Claude superestimou tarefas curtas de software e subestimou as longas.¹⁴ Colocar os trabalhos mais ou menos na ordem certa não basta quando os pesos relativos decidem o resultado.

Um sistema de pontos poderia adotar controles parecidos. Eu não ganho a discussão só trocando o nome. O teste é se outro time consegue aplicar as definições e se uma divergência razoável muda a conclusão.

Se isso não se sustenta, então sim, reinventei o story point em dólar.

Terminamos ou só paramos de falar do assunto?

O Fin dá um exemplo concreto útil. A Intercom conta resoluções confirmadas e presumidas, em que o cliente sai depois de uma resposta sem pedir mais ajuda. A documentação dela também diz que a cobrança é estornada se o cliente voltar à mesma conversa pedindo mais assistência.¹⁵

É uma regra de cobrança clara. Ela deixa uma pergunta sobre clientes em silêncio, mas é injusto discuti-la sem a regra do estorno. E conversas encerradas por humanos merecem o mesmo escrutínio.

Para este índice, eu especificaria o que conta como conclusão para cada tipo de trabalho. Às vezes há uma aceitação explícita. Às vezes há um teste, um registro de pagamento ou evidência de entrega. Às vezes só temos sinais indiretos e precisamos mostrar essa incerteza. “Fechado” não resolve todos os casos.

Retrabalho também não é simples. Uma conversa reaberta pode ser uma resposta que falhou ou uma pergunta nova. Um rollback de código pode corrigir um defeito ou refletir uma decisão de produto que mudou. Uma disputa posterior não invalida automaticamente o parecer jurídico que veio antes.

Precisamos de uma regra para saber quais correções revertem a produção anterior, quanto revertem e quais pertencem a um escopo novo. Use-a para pessoas e agentes por igual. Compare trabalhos que tiveram a mesma oportunidade de revelar defeitos e revise o período original quando o crédito anterior deixar de se sustentar. Uma fila recém-fechada não deveria parecer melhor só porque ninguém teve tempo de reclamar.

A checagem também consome recursos. Os cenários de revisar e refazer do GDPval mostram quanto a vantagem de custo aparente pode mudar quando se inclui a revisão de especialistas. São cenários modelados, não economias observadas em empresas, e o artigo observa que custos equivalentes de revisão e falha não estão incluídos na referência humana.¹⁶ Eu gostaria de ver o fluxo inteiro com custo calculado dos dois lados.

O planejamento expôs um erro diferente na minha versão anterior. Eu sugeri não dar crédito nenhum a um ciclo de previsão se os ajustes do planejador o piorassem. Isso confundia concluir o trabalho com obter um resultado favorável.

O forecast value added é útil para avaliar ajustes sobre observações comparáveis.¹⁷ Não é uma chave universal para saber se o planejamento aconteceu. Uma previsão sólida pode cumprir o escopo e mesmo assim se mostrar errada. Um bom parecer jurídico pode barrar um negócio. Um experimento pode ser útil justamente porque nos diz para abandonar o projeto.

Se a medida só reconhece boas notícias, vai deixar passar trabalho bom.

Quarenta rascunhos de quê?

Agora dê ao índice um pouco de trabalho de marketing.

Um time produzia quatro variações de anúncio por semana. Cada uma levava duas horas, o que dá a cada uma um peso de referência de $80 na nossa taxa ilustrativa. A produção da semana era $320.

Com IA, ele produz quarenta. Aplique o peso a cada arquivo gerado e a produção vira $3.200, enquanto os resultados da campanha mal se mexem.

No começo tratei isso como prova de que a medida estava quebrada. Pode estar, mas não pelo motivo que eu pensei. Quarenta entregas distintas e comparáveis podem ser dez vezes a produção sem ser dez vezes mais úteis. Eu já tinha dito que não estava medindo valor, e depois esperei que o número medisse mesmo assim.

A outra pergunta é se aqueles quarenta arquivos eram quarenta entregas. Podem ser rascunhos usados para escolher o que entra em um único experimento.

Neste exemplo, suponha que o serviço seja um experimento de campanha para um público especificado, com uma pergunta de teste definida e requisitos de relatório. Eu contaria esse experimento. Gerar quatro rascunhos ou quarenta não muda a unidade. A produção e a seleção deles fazem parte do custo.

Se o time faz outro experimento genuinamente distinto, de escopo comparável, isso é mais produção. Chamar dez variações do mesmo teste de dez experimentos não é. A gente precisaria da definição antes de ver o resultado, não de uma explicação criativa depois.

Em outro fluxo, produzir variações prontas para uso pode ser o próprio serviço. Aí cada variação pode ser a unidade certa. É outro limite de relatório, e eu não alternaria entre os dois conforme qual deles desse o número maior.

Tom Cunningham e Parker Whitfill, da METR, ajudaram a esclarecer por que a pergunta sobre valor continua separada. Eles distinguem o efeito da IA sobre o conjunto antigo de tarefas, sobre o novo e sobre o valor produzido. Tornar algo barato muda o que as pessoas escolhem tentar, além de quão rápido terminam a carga de ontem.¹⁸

Concordo em separar essas perguntas. Uma contagem de produção não vira medida de valor porque o trabalho era caro antes. Nem a aprovação de um gerente faz quarenta variações serem quarenta vezes mais úteis que uma.

O que acontece quando uma etapa desaparece?

Software quebra a contagem na direção oposta.

Suponha que uma funcionalidade antes exigisse uma especificação de três horas, dez horas de implementação e duas horas de revisão. A $40 por hora, o custo de referência é $600.

Agora um agente consegue construir a mesma funcionalidade a partir do contexto que já existe. O uso custa $25. A revisão humana leva três horas, o que representa $120 de esforço na nossa taxa. Os recursos modelados somam $145. Suponha que a funcionalidade cumpra os mesmos requisitos e as mesmas checagens de qualidade.

Se eu contar as etapas do processo antigo, perco a especificação. A implementação e a revisão que sobraram têm pesos antigos que somam $480. Mas o negócio recebeu a funcionalidade inteira.

Contar etapas perde 20% da produção porque um documento se tornou desnecessário. Contar a funcionalidade inteira mantém a comparação intacta.

Isso só funciona se a etapa realmente era desnecessária. Remover uma checagem de segurança ou abandonar um requisito mudaria o que foi entregue. “A mesma funcionalidade, no mesmo padrão” está fazendo um trabalho importante nessa frase.

“A funcionalidade inteira” também. Não pode significar qualquer coisa que por acaso se chame pedido. Divida uma funcionalidade em três tickets e ela não deveria ganhar três pesos de funcionalidade. Junte três funcionalidades genuínas num épico e duas não deveriam sumir.

Depois vêm os pais e os filhos. Se a funcionalidade de ponta a ponta já inclui design e revisão, não posso somar o peso dela ao mesmo trabalho contado de novo por esses times. Dá para atribuir contribuições dentro do total. Não dá para criar produção extra da empresa passando-a de um departamento para outro.

Tente reorganizar o mesmo trabalho sem mudar o que é entregue. O total da empresa deve ficar parado. Tente terceirizar uma parte. Mesmo teste.

Projetos longos também exigem cuidado com o tempo. Eu usaria comparações acumuladas ou marcos independentemente úteis cujos pesos somem o escopo combinado. Do contrário, meses de custo levam a um único pico enorme de conclusão, e um painel mensal passa a maior parte do ano enganando.

Tá, mas o que conta como a mesma funcionalidade?

Fui bem generoso comigo mesmo com aquela funcionalidade de quinze horas. Uma correção ortográfica e um sistema de cobrança podem ambos ser chamados de funcionalidade. Colocá-los na mesma categoria nos levaria direto de volta ao problema do suporte.

Vamos escolher algo mais específico: uma exportação em CSV do histórico de auditoria de um cliente. Um administrador de conta autorizado precisa exportar oito campos especificados para um intervalo de datas escolhido. O briefing define o volume e os limites de tempo de resposta, os requisitos de precisão e os controles de acesso. Precisa funcionar no produto em produção.

Eu contaria uma capacidade de exportação entregue desse escopo. Não o botão, o endpoint, os testes e a documentação separadamente. Também não contaria toda vez que alguém baixasse o arquivo. Aqui estamos medindo a entrega de uma mudança, não a operação do produto depois.

Nessa empresa fictícia, suponha que encontremos cinco mudanças anteriores de exportação de relatórios com escopo de dados, comportamento de usuário, limites operacionais e requisitos de garantia comparáveis. Na mesma base de preços de referência, os custos de ponta a ponta foram $480, $560, $600, $640 e $720. A média é $600.

Assim é que poderíamos construir o peso. Cinco números convenientes não provam que ele é bom. O revisor precisa conferir o que tornava aqueles trabalhos comparáveis, em vez de simplesmente procurar a palavra “exportação”. Depois testaríamos a classe e o peso dela em outros trabalhos.

Agora temos uma definição para discutir:

Repare que a classe não depende da implementação escolhida, do número de pull requests nem do salário do engenheiro. Isso pode afetar o custo sem mudar o que o negócio recebeu.

O fluxo de eventos é diferente. Ele muda o comportamento exigido. Precisaríamos de uma classe de referência adequada ou de outro tratamento explícito para esse escopo, aplicado de forma consistente ao trabalho anterior e ao posterior. Não podemos inventar uma categoria de “exportação muito complexa” depois de uma construção cara e dar a ela mais produção.

E uma nova plataforma de relatórios sem precedente crível? Eu não a forçaria nessa classe. Descreveria o escopo, os custos e os marcos úteis, e a manteria fora dessa série comparável até termos uma base para incluí-la.

O custo dela precisa continuar visível. O relatório precisa reconciliar o serviço medido com o trabalho não correspondido e o restante dos gastos. Do contrário, eu estaria escolhendo os sucessos fáceis de classificar e deixando todo o investimento difícil em outro lugar.

Essa é a parte mais difícil da proposta. Outro revisor poderia rejeitar a classe de exportação ou o peso de $600. Pelo menos dá para localizar a divergência e ver se outra escolha razoável muda a resposta.

Parte do trabalho de engenharia pode sustentar classes assim. Parte pode não sustentar. Descobrir isso seria um resultado útil, mesmo que acabe com a minha esperança de um total para a empresa inteira.

As sessenta horas não saíram da folha de pagamento

De volta ao suporte e à economia que eu fiquei tentado a reportar.

Originalmente, 180 horas de atendimento a $40 davam $7.200. Depois, 120 horas dão $4.800. Some uma cobrança ilustrativa do agente de $0,80 por cada uma das suas 600 resoluções e o custo de atendimento alocado é $5.280.

São $1.920 a menos. Só que as pessoas continuam empregadas nas mesmas condições.

Suponha que a folha de pagamento neste exemplo simplificado continue em $7.200. Some a conta de $480 do agente e a empresa gasta $7.680. A necessidade de atendimento caiu. A conta subiu.

Robert Kaplan e Steven Anderson fazem essa distinção no trabalho deles sobre custeio baseado em atividades orientado por tempo: a capacidade ociosa oferece oportunidades de economia ou de crescimento.¹⁹ Concordo, e isso muda a regra aqui. Horas liberadas vão para uma linha de capacidade. Economia exige evidência de gasto reduzido ou um relato crível de gasto evitado.

As sessenta horas poderiam sustentar mais clientes sem outra contratação. Poderiam reduzir hora extra, absorver picos ou deixar o trabalho menos frenético. Também poderiam ficar sem uso. Não quero que a contabilidade escolha um desfecho antes de a empresa ter feito alguma coisa com esse tempo.

Para o índice principal de eficiência de custo, eu usaria o custo de fornecer o serviço medido, incluindo o trabalho malsucedido e a capacidade que ficou ociosa. Compare o crescimento da entrega com o crescimento do custo:

E_t = 100 × D_t / D_bC_t / C_b

(3)

D é o total entregue. C é o custo dentro do mesmo limite de relatório. E começa em 100, então 100 significa nenhuma mudança na eficiência de custo.

No exemplo do suporte, a entrega fica em $7.200 enquanto o gasto sobe de $7.200 para $7.680. O índice é 93,8: a eficiência de custo caiu 6,25% naquele mês.

Use o modelo separado de atendimento alocado e a razão é 136,4. Essa é a melhora nos recursos necessários para o fluxo, não um ganho financeiro realizado. Os dois números são úteis depois de rotulados. Pôr “economia de IA” acima de qualquer um dos dois pouparia muita explicação e criaria um problema bem maior.

Para uma conta de custos real, inclua folha de pagamento e encargos, terceirizados, serviços comprados, licenças, uso de agentes e infraestrutura. Revisão, manutenção e medição também consomem recursos. Não some o trabalho de revisão duas vezes se ele já está no total da folha.

A tarifa de um prestador entra na conta uma vez, junto com a nossa supervisão. Não inventamos também a folha de pagamento interna e os custos de tokens dele. Terceirizar não deve fazer o custo da compra desaparecer, nem contá-lo duas vezes.

Também precisamos de uma base consistente ao longo do tempo. Despesas do período não são pagamentos em caixa. Uma construção paga neste trimestre pode servir por vários anos. Escolha e divulgue o tratamento. Não lance a construção como despesa numa comparação e a distribua por anos em outra. O exemplo do suporte supõe que despesa e gasto em caixa coincidem.

Preços importam também. Tokens mais baratos melhoram a economia mesmo que nada no fluxo mude. Um aumento salarial faz o contrário. Onde quantidades de insumos e qualidade podem ser comparadas, uma visão a preços constantes ajuda a separar mudanças de preço do uso de recursos. Sem essa evidência, mostre o resultado de custo nominal e explique os limites dele.

Por fim, sessenta horas a menos de atendimento não provam que uma posição inteira pode sair. O quadro de pessoas ainda precisa cobrir o trabalho quando ele chega. A próxima pergunta é sobre demanda e compromissos de serviço, não sobre dividir por um número conveniente de horas.

O erro que eu achei que se cancelaria

Eu tinha escrito que um peso errado se cancelaria quando comparássemos um time com ele mesmo. O mesmo erro aparece dos dois lados, então estamos seguros, certo?

Não. Não quando a mistura se move.

Pegue dois tipos de trabalho. Neste exemplo, estipule que os pesos de referência corretos são $1 para o trabalho simples e $10 para o complexo. No primeiro trimestre, o time conclui noventa unidades simples e uma complexa. No segundo, dez simples e nove complexas. A produção ponderada corretamente é $100 nos dois trimestres. Mantenha também o total de recursos inalterado.

Agora dê ao trabalho complexo um peso incorreto de $20.

Reportamos 72,7% de crescimento onde não houve nenhum na medida ponderada corretamente. O erro ficou fixo. Nós fizemos mais do trabalho que tínhamos superavaliado.

Um peso errado pode fabricar crescimento

i

Crescimento real 0,0%. O índice diz +72,7%. O mesmo trabalho, outra mistura.

Quão errado está o peso do trabalho complexo?+100%

Unidades complexas no trimestre 29

Errar também o peso do trabalho simples no mesmo valor

A relação é:

ĜG = 1 + ē_t1 + ē_b,ē_t = Σ_k w_k,t e_k

(4)

G é a razão de crescimento usando os pesos corretos no exemplo. Ĝ usa os nossos pesos estimados. e é o erro proporcional de peso de cada tipo e w é a sua participação na produção ponderada corretamente. ē é o erro médio depois de ponderar por essas participações.

Os erros se cancelam quando essa média é a mesma nos dois períodos. Uma mistura de trabalho inalterada resolveria. Errar todos os pesos na mesma proporção também. Outras combinações também podem se cancelar. Essas duas não são as únicas possibilidades.

A checagem prática é olhar o que ganhou participação. Se a melhora aparente vem de uma categoria em cujo peso a gente mal confia, teste alternativas plausíveis. O ganho sobrevive? Os resultados por tipo devem ficar ao lado do total, sem exigir um pedido especial de quem duvida.

As categorias podem esconder outro deslocamento. Se o agente pega o mais fácil dos “casos fáceis”, até o meu modelo de suporte com duas categorias pode se ajustar pouco. Precisamos conferir o que mudou dentro de cada categoria também.

A gente também pode melhorar na forma de enxergar o trabalho

Mesmo com pesos perfeitos, os registros podem nos enganar.

Suponha que a produção real cresça 10%. Capturamos 80% da produção ponderada corretamente no primeiro período e 84% no segundo. A comparação observada fica:

D̂_tD̂_b = 1,10 × 0,840,80 = 1,155

(5)

O painel mostra 15,5% de crescimento. Quatro pontos percentuais de cobertura melhor acrescentaram 5,5 pontos percentuais ao crescimento aparente. Sem nenhum crescimento real, essa mesma mudança de cobertura fabricaria 5%.

Um agente pode deixar um log exaustivo de um trabalho que uma pessoa teria concluído numa conversa. Registros melhores seriam bem-vindos. Mas, por si só, não seriam mais produção.

“Cobertura” nessa equação significa a parcela da produção capturada, ponderada na mesma base de referência. Não significa a porcentagem da folha de pagamento ligada a uma integração, licenças conectadas ou gasto visível.

Saber para onde foram 80% do dinheiro não nos diz que encontramos 80% do trabalho. Isso só decorre de outras suposições sobre o trabalho observado e o que falta. Mantenha a cobertura de gasto como checagem financeira útil. Não a ponha na equação da produção só porque é mais fácil de obter.

É por isso que mantive o exemplo de cobertura, mesmo deixando o sistema de coleta de evidências fora do texto. Uma mudança no que a gente consegue ver muda a medição, seja qual for o jeito de coletar os registros.

Mais registros não resolvem isso automaticamente. Volume pode reduzir o ruído aleatório. Um viés consistente pode continuar. Quatro trimestres de dados também não reduzem a incerteza pela metade automaticamente. Erros compartilhados entre trimestres não se comportam como erros independentes.

Prefiro publicar uma série mais estreita que observamos de forma consistente a fazer uma afirmação sobre a empresa inteira numa cobertura que não conseguimos defender. Ela precisa de um limite claro, das mesmas janelas de acompanhamento e de checagens de mudanças no registro. O trabalho fora desse limite continua visível como trabalho não medido.

Simulações anteriores me ajudaram a explorar esses erros. Eu não mantive as faixas numéricas delas como evidência de quão preciso o método seria. Isso exige publicar a implementação e as premissas, e depois conferir contra trabalho real. Os exemplos aqui estabelecem os modos de falha sem fingir saber com que frequência cada um vai ocorrer.

Em algum momento, até a linha de base vira problema

Não dá para congelar um conjunto de pesos para sempre e supor que o negócio vai ter a gentileza de continuar comparável. Serviços mudam. Alguns desaparecem, e os novos não vêm com um preço antigo.

Uma opção é atualizar os pesos periodicamente, comparando cada par de períodos adjacentes com os mesmos pesos. Um encadeamento anual usando os pesos do ano anterior é:

L_t = Σ_k n_k,t s_k,t−1Σ_k n_k,t−1 s_k,t−1

(6)

O numerador conta a produção deste ano usando os pesos do ano passado. O denominador conta a produção do ano passado com esses mesmos pesos. Multiplique os encadeamentos para um índice de prazo mais longo.

Isso evita chamar uma mudança de pesos de mudança na produção. Também tem um porém: componentes encadeados separadamente em geral não somam o total encadeado. O BEA alerta explicitamente contra tratar componentes em dólares encadeados como aditivos.²⁰

Então construa a série da empresa a partir do seu próprio conjunto de entregas sem sobreposição. Não some painéis de times desenhados de forma independente esperando que meçam coisas compatíveis. Parte do trabalho interno pode ser útil numa visão por função, mas já estar incluída na entrega de ponta a ponta da empresa.

Uma classificação alterada também precisa de uma ponte: um período de sobreposição, uma reconstrução crível da série anterior ou uma ruptura declarada. Encadear não conserta uma definição ruim de serviço nem trabalho ausente que só acabamos de encontrar.

Isso pode nos deixar com comparações úteis por função e nenhum total defensável para a empresa toda. Eu aceitaria. Seria melhor do que inventar um total porque o pedido original exigia um.

Às vezes o bom trabalho diminui a contagem

Suponha que a engenharia corrija o defeito por trás de mil conversas de suporte. Nosso índice de casos de suporte reporta menos casos atendidos.

E deve mesmo. Houve menos casos. O erro seria concluir que a empresa ficou menos produtiva.

Num limite mais amplo, estamos tentando ajudar os clientes a usar o produto com sucesso. Manter ou melhorar esse serviço com menos contatos evitáveis pode ser um ganho substancial. A contagem estreita de casos precisa da definição mais ampla de serviço ou das medidas de resultado ao lado.

Confiabilidade e prevenção têm o mesmo problema. Uma semana tranquila de plantão pode ser uma boa semana. Uma intervenção de compliance útil pode impedir que um caso sequer exista.

Para essas funções, eu testaria unidades baseadas no serviço mantido durante um período: o que foi mantido funcionando, para quem, sob que carga e risco, em que padrão. Uma entrada na escala de plantão não basta. Também não transformaria a produção de um mês em zero porque um limite foi descumprido. O ajuste de qualidade precisa refletir a falha, em vez de fazer tudo depender de uma única chave.

Essas unidades são mais difíceis de definir. Isso faz parte do problema que estou tentando entender, não algo que uma contagem de tickets nos deixe evitar.

E o trabalho que a gente não conseguia fazer antes?

Um time de auditoria que amostrava transações agora pode examinar todas. Ponha o antigo custo humano hipotético em cada checagem adicional e a alegação de produção fica enorme.

Mas ninguém necessariamente ia comprar aquele processo manual. Mais checagens também não significam um aumento proporcional de garantia.

Se o novo serviço é comparável a algo que já medimos, dá para contabilizar a mudança de escopo ou de qualidade nessa base. Se não é, eu reportaria separadamente a capacidade, o custo e o que esperamos que ela alcance, enquanto estabelecemos uma definição útil.

Estou chamando isso de livro-razão de capacidades. Não significa que o gasto se qualifica para capitalização. Não significa que a gente pode esconder trabalho caro sob “inovação” sempre que a razão de eficiência decepciona. A conta ainda precisa reconciliar com as finanças.

Quando o serviço se torna repetível e definível, ele pode entrar no índice de entrega sob uma regra explícita de introdução. Ser viabilizado pela IA não deveria mantê-lo de fora para sempre.

Aqui o argumento de Acemoglu sobre a demanda corporativa volta. Se as empresas só recompensam economia de custo de trabalho, só vão comprar ferramentas que substituem pessoas.¹ Um livro-razão de capacidades é um jeito de recompensar o outro tipo.

Minha contribuição aqui é mais estreita. Dar à empresa um lugar para explicar o que o investimento torna possível, em vez de pedir que todo projeto se justifique como trabalho antigo mais barato. Um responsável, evidências e uma data de revisão seriam um bom começo. “É IA” não é um caso de investimento.

Acemoglu também argumenta contra distorções tributárias que favorecem o capital em relação ao trabalho, com base em trabalho feito com Andrea Manera e Pascual Restrepo.¹²¹ Concordo em remover uma preferência artificial pela substituição. Para este texto, porém, a decisão está dentro do orçamento: quanto o serviço existente custa agora, e o que a gente consegue fazer que antes não conseguia?

O livro-razão não vai tomar essa decisão por nós. Deveria torná-la mais difícil de evitar.

Eu colocaria isso na frente de um CFO?

Sim, mas junto com o resto da conta, não como uma nota para a empresa.

Kent Beck e Gergely Orosz fazem um argumento forte contra metas de esforço e de produção na resposta deles à McKinsey. Ao discutir as métricas customizadas dela, escrevem: “Customers don’t care. Executives don’t care. Investors don’t care.”²²

Acho que essa rejeição vai longe demais. Um CFO pode perguntar, com razão, se conseguimos entregar o mesmo serviço de folha de pagamento, no mesmo padrão, com menos recursos. Não deveríamos ter que esperar um movimento no lucro da empresa para investigar por que ele ficou mais caro.

O argumento deles é mais matizado do que essa frase. Eles também reconhecem o uso de esforço e produção para diagnosticar problemas, e os perigos de julgar pessoas só por resultados.¹³ Na seção final, Orosz recomenda usar esforço e produção para investigar problemas, em vez de torná-los as medidas públicas de sucesso.

Essa é a discordância mais estreita que vale ter. Acho que uma comparação reportada regularmente da produção e do custo de um serviço definido pode ajudar, ao lado dos resultados. Ela precisa justificar o próprio custo e o efeito no comportamento. Um painel lindo que transforma o time em melhorador de painel em tempo integral fracassou.

Isto é mais ou menos o que eu gostaria de ver:

As medidas de resultado devem variar por função. Bookings pertencem a uma conversa de vendas. Não são um teste de aceitação sensato para um parecer jurídico. Prefiro mostrar essas diferenças a escondê-las dentro de um “multiplicador de impacto”.

No nível da empresa, a conta financeira também precisa refletir como compramos o trabalho. A receita por funcionário pode subir depois de uma terceirização mesmo que o custo total de entrega suba. Some os serviços comprados e os custos de IA relevantes antes de decidir que o negócio ficou mais eficiente. A receita ainda tem outros fatores, então essa razão não vai atribuir a mudança à IA.

Eu não usaria o índice de entrega para ranquear indivíduos. Os pesos dele descrevem classes de trabalho, não a contribuição completa de uma pessoa. Mentoria, interrupções e ajudar outra pessoa a terminar um trabalho não cabem na contagem de produção de um indivíduo. Amarre o salário ao índice e damos às pessoas um motivo para defender pesos maiores e mais trabalho contável.

Até comparar trabalho assistido por IA com trabalho só humano exige o mesmo cuidado do exemplo de abertura. As atribuições podem diferir dentro de uma categoria. Saber que um agente participou não prova que ele causou a melhora.

E um artefato concluído não prova que a pessoa responsável o entendeu. Esse é outro problema, principalmente se afirmamos que o objetivo é tornar as pessoas mais capazes.

O teste que eu ainda não fiz

Mostrei como alguns cálculos se comportam com insumos que eu escolhi. Peguei emprestados métodos de contabilidade e aprendi com as objeções dos outros. Nada disso me diz se dois times conseguem usar esta proposta em trabalho real e chegar a um resultado útil.

Esse é o próximo teste.

Eu começaria com três contextos: um fluxo repetível de casos ou transações, um fluxo de projeto e um serviço contínuo. Para cada um, escreva a unidade, o escopo e o limite do relatório antes de ver os resultados. Acrescente a regra de conclusão, o tratamento de qualidade, os pesos de referência e a base de custo. Diga o que acontece com o trabalho não correspondido e com as correções posteriores.

Depois dê a mesma evidência a outro time competente. Eles conseguem reproduzir o cálculo? Onde discordam sobre o que pertence a ele?

A aritmética deve ser fácil de acordar. O exemplo da exportação mostra onde vai estar a discussão de verdade. Se duas escolhas razoáveis de categoria invertem o resultado principal, o relatório precisa mostrar isso, em vez de resolver a divergência com uma casa decimal.

Escolha as classes de referência e estime os pesos delas usando um conjunto de trabalho, depois teste em outro. Inclua na revisão os registros excluídos e o trabalho fora do sistema principal de acompanhamento. Não redesenhe as categorias até o histórico parecer convincente.

Repita os testes de ticket dividido, ticket mesclado, reorganização e terceirização. Procure mudanças no registro. O total da empresa não deveria se mover quando tudo o que mudamos foi como descrevemos ou compramos o mesmo trabalho.

Primeiro teste essa contabilidade com um relato do trabalho estabelecido de forma independente. Se uma máquina consegue recuperar esse relato a partir dos sistemas disponíveis é um teste de implementação para depois. Se humanos com evidência adequada não concordam sobre as unidades, um classificador melhor não vai salvar a definição.

Testar se a IA causou uma melhora é outro trabalho. Acesso randomizado pode ajudar onde for viável, assim como uma implantação em etapas bem desenhada com um grupo de comparação crível. Aprendizado, efeitos colaterais, seleção de tarefas e acompanhamento de qualidade equivalente importam. Adotantes entusiasmados e relutantes não são automaticamente comparáveis só porque têm o mesmo cargo.

Quão preciso a medida precisa ser? Depende da decisão. Um sinal aproximado para saber onde investigar tem um ônus diferente de uma evidência usada para cortar pessoal ou reportar economia. O erro aceitável deve seguir essa decisão, não um tamanho universal de amostra de auditoria.

Publique as definições, o cálculo e a política de revisão junto com o resultado. Meu critério é que outro time consiga aplicar o método, questionar as escolhas dele e ver se a conclusão sobrevive. O reconhecimento de um contador ou uma equação de aparência impressionante não bastaria.

Agora eu tenho uma pergunta melhor

Comecei com “a IA nos deixou mais produtivos?”. Agora quero saber qual serviço mudou, se estamos contando a mesma coisa e para onde foi a capacidade liberada. Essas perguntas são menos convenientes num slide. São muito mais úteis quando alguém pergunta o que a gente deve fazer em seguida.

Isso importa para a Flowstate porque conectar o trabalho aos recursos por trás dele é o problema que a gente está tentando resolver. Não quero que o produto dependa de defender uma fórmula por que me apeguei enquanto escrevia um post de blog. Se o trabalho real quebrar o modelo, o modelo tem que mudar.

Eu ainda quero que os agentes tirem o trabalho repetitivo do dia das pessoas. Quero que uma empresa reconheça o benefício quando alguém ganha tempo para pensar, ajuda um colega ou tenta algo novo, em vez de exigir mais tickets para provar que a compra do software deu certo.

Não sei quanto disso cabe em um índice. Talvez menos do que eu esperava. Um resultado útil pode ser um conjunto de comparações em que a gente confia, com as lacunas à vista de todo mundo.

Quando o agente pega os casos fáceis, as pessoas que ficam não deveriam precisar fabricar atividade para se defender. Quando alguém alega uma economia, a gente deveria poder perguntar para onde ela foi. E quando o número proposto não responde à pergunta, a gente deveria dizer isso antes que ele vire a meta de alguém.

Fui procurar uma medida. Acabei com um método que eu testaria e uma lista bem longa de motivos para ter cuidado. Considerando de onde comecei, acho que isso é progresso.

Notas técnicas

Estes são os cálculos por trás dos exemplos. As premissas importam: uma identidade pode ser exata sem nos dizer com que precisão conseguimos estimar os insumos dela numa empresa. As razões abaixo supõem pesos de referência positivos e denominadores diferentes de zero.

A identidade do erro de peso

Seja o peso de referência correto estipulado para o tipo k igual a s, e seja o peso estimado:

ŝ_k = s_k(1 + e_k)

(7)

Para uma produção contada com precisão, defina o total ponderado correto e a participação de cada tipo como:

D_t = Σ_k n_k,t s_k,w_k,t = n_k,t s_kD_t

(8)

Então:

D̂_t = Σ_k n_k,t s_k(1 + e_k) = D_t(1 + ē_t)

(9)

Tomar a razão entre períodos dá a identidade usada acima. Ela supõe erros proporcionais de peso fixos por tipo, quantidades precisas e uma definição comum de produção. Não modela trabalho omitido, classificações que mudam nem limites incertos de entregas.

Para erros pequenos, o erro relativo na razão de crescimento é aproximadamente:

ĜG − 1 ≈ Σ_k (w_k,t − w_k,b) e_k

(10)

Se, além disso, os erros por tipo forem variáveis aleatórias independentes, de média zero e com o mesmo desvio padrão, o desvio padrão de primeira ordem desse erro na razão de crescimento é:

σ_G ≈ σ_e √Σ_k (w_k,t − w_k,b)²

(11)

Sob essas premissas específicas, transferir vinte pontos percentuais de participação na produção entre dois tipos e fixar o desvio padrão do erro em 20% dá aproximadamente 5,66% de erro relativo na razão de crescimento, um desvio padrão. Não é uma faixa de erro estabelecida empiricamente, e em geral não é o mesmo número de pontos percentuais de crescimento reportado. Padrões correlacionados ou sistematicamente enviesados exigem outro cálculo.

Cobertura é um conceito de produção na identidade

No exemplo só de cobertura, seja c a parcela da produção ponderada corretamente que fica visível nos registros, sem falsos positivos e sem outros erros. Então a produção observada é c vezes a produção completa, e portanto:

D̂_t / D̂_bD_t / D_b = c_tc_b

(12)

A equação é exata sob essas definições. Estimar c é a parte difícil. Uma razão entre gasto conectado e gasto total é outra estatística e não pode ser substituída sem um modelo explícito que ligue a cobertura de recursos à cobertura de produção.

O limite contábil importa aqui também. Observar parte da produção usando toda a base de custo não estima o mesmo objeto que medir produção e custo para um serviço deliberadamente restrito e observado de forma consistente. Nenhum dos dois deve ser rebatizado de eficiência da empresa inteira sem justificativa.

Por que a acurácia geral de um classificador não basta

Para um problema binário simples de reconhecimento, com pesos fixos e corretamente atribuídos, defina os totais de verdadeiros positivos, falsos positivos e falsos negativos usando esses pesos em vez de contagem de itens. A precisão ponderada é o peso dos verdadeiros positivos dividido por todo o peso reconhecido. O recall ponderado é o peso dos verdadeiros positivos dividido por todo o peso elegível. Onde os denominadores são diferentes de zero:

peso reconhecidopeso elegível = recall ponderadoprecisão ponderada

(13)

Precisão e recall comuns, baseados em contagem, não dão essa identidade para um índice ponderado por custo. Uma classificação errada que muda o peso de um item reconhecido exige tratamento adicional. Assim como candidatos que nunca foram encontrados e relações incertas entre registros pai e filho. Combinar esses erros numa única equação multiplicativa exige definições compatíveis. Isso não se justifica só porque cada termo tem um nome plausível.

O reconhecimento probabilístico é possível, mas um estimador proposto precisa manter as classificações mutuamente exclusivas e evitar contar entregas sobrepostas. Um conjunto de tickets pontuados de forma independente não satisfaz essas condições automaticamente. Probabilidades calibradas tratam da incerteza nos candidatos observados, não do trabalho que está totalmente ausente do conjunto de candidatos.

O que uma amostra de auditoria consegue estabelecer

A conhecida estimativa de 385 observações vem de um cálculo particular: uma amostra aleatória simples de uma proporção binária independente, um intervalo de 95% por aproximação normal, uma proporção de pior caso de um meio e uma margem de cinco pontos percentuais. O tamanho de amostra sem arredondar é:

n ≈ 1,96² × 0,5 × 0,50,05² = 384,16

(14)

Isso não estabelece que 385 registros vão calibrar custos de referência, validar todo tipo de trabalho ou resolver uma pequena mudança entre períodos. Estratificação, agrupamento, pesos desiguais, casos raros de alto custo e divergência entre revisores mudam o desenho necessário. O planejamento da auditoria deve partir do erro que poderia mudar a decisão de negócio, não de um número redondo conhecido.

Reprodutibilidade e interpretação

Os exemplos trabalhados usam os insumos declarados. Não são estimativas do desempenho típico de uma empresa. Faixas de erro numéricas de Monte Carlo também precisariam da implementação, das distribuições dos parâmetros, das premissas de dependência e das sementes aleatórias publicadas. Depois precisaríamos estabelecer quais premissas se ajustam ao trabalho observado antes de interpretar as faixas como acurácia esperada.

A soma da entrega tem unidades de moeda de custo de referência. Um índice de apresentação pode normalizar essa soma para 100 no período-base. O índice de eficiência de custo já usa essa normalização. Nenhum dos dois mede valor econômico, impacto causal da IA ou o valor de um funcionário.

Will Hackett é cofundador e CTO da Flowstate.

Footnotes

1. Daron Acemoglu, Will AI Replace Workers? Not If We Build It Right., The Humanist Review of AI, 15 de julho de 2026. Defende ferramentas que complementem os trabalhadores e uma demanda corporativa centrada em produtividade e inovação, não só em economia de custo de trabalho. A ligação com o desenho de relatórios aqui é inferência minha, não um método proposto nesse ensaio. Fonte. ↩ ↩² ↩³

2. National Association of Letter Carriers, The Remote Encoding Center: Where bad addresses go to get better, The Postal Record, julho de 2022, pp. 34 e 35. O relato descreve máquinas pegando as imagens de endereço mais fáceis e deixando as mais difíceis para digitadores humanos. Fonte. ↩

3. Intercom, How Fin AI Agent and Copilot Cut Handle Time and Boost Agent Productivity. A discussão sobre a carga de casos humana que sobra é comentário de fornecedor que apoia o mecanismo da mistura de trabalho, não evidência independente do tamanho de um ganho de produtividade. Fonte. ↩

4. Erik Brynjolfsson, Danielle Li e Lindsey Raymond, Generative AI at Work, The Quarterly Journal of Economics 140(2), 2025, pp. 889 a 942. O estudo publicado relata um aumento médio de 15% nos chamados resolvidos por hora no contexto de suporte ao cliente, com efeitos diferentes de velocidade e qualidade entre os trabalhadores. Artigo publicado. Resumo dos autores. ↩

5. Joel Becker, Nate Rush, Beth Barnes e David Rein, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, METR, 10 de julho de 2025. O resultado diz respeito aos desenvolvedores experientes participantes, aos repositórios deles e às ferramentas disponíveis naquele experimento. Fonte. ↩

6. Joel Becker e colegas, We are Changing our Developer Productivity Experiment Design, METR, 24 de fevereiro de 2026. O acompanhamento discute a seleção de participantes, a seleção de tarefas e as dificuldades de medir tempo com agentes concorrentes. Fonte. ↩

7. McKinsey, The state of AI in 2026: On the road to ROI, 25 de agosto de 2026. As respostas da pesquisa foram coletadas de 1.719 participantes entre 4 de maio e 8 de junho de 2026. Os números reportados de 80% de produtividade individual e 37% de impacto no EBIT respondem a perguntas diferentes. Fonte. ↩

8. Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck e Jenna Butler, The SPACE of Developer Productivity: There’s more to it than you think, ACM Queue 19(1), 2021. Argumenta que a produtividade de desenvolvedores não cabe em uma única métrica ou dimensão. O índice de entrega delimitado proposto aqui não é apresentado como substituto desse framework. Fonte. ↩

9. Alessandro Berti e colegas, OCEL (Object-Centric Event Log) 2.0 Specification, arXiv:2403.01975, enviado em 4 de março de 2024. A especificação oferece suporte a eventos e relações que envolvem vários objetos de negócio. É um padrão de representação, não uma métrica de produtividade. Fonte. ↩

10. ACCA, The standard hour in performance measurement. Horas-padrão fornecem uma medida comum de atividade para produtos heterogêneos e sustentam razões separadas de volume, utilização e eficiência. Fonte. ↩

11. Office for National Statistics, Public service productivity estimates: sources and methods, revisado em 1 de maio de 2026, especialmente a seção 1 sobre produção, insumos e números-índice. A metodologia usa medidas de atividade ponderadas por custo para boa parte da produção de serviços públicos, mas não toda. Fonte. ↩ ↩²

12. Ron Jeffries, Story Points Revisited, 23 de maio de 2019. O pedido de desculpas condicional dele por possivelmente ter inventado os story points é a referência aqui, não evidência contra toda forma de estimativa relativa. Fonte. ↩

13. Gergely Orosz e Kent Beck, Measuring developer productivity? A response to McKinsey, Part 2, The Pragmatic Engineer, 31 de agosto de 2023. A discussão conjunta trata de incentivos baseados só em resultados. A seção final, identificada separadamente, é de Orosz e inclui o exemplo de inflação de estimativas e a recomendação de usar esforço e produção para diagnosticar problemas, não como medidas públicas de sucesso. Fonte. ↩ ↩²

14. Alex Tamkin e Peter McCrory, Estimating AI productivity gains from Claude conversations, Anthropic, 25 de novembro de 2025. A checagem com tarefas de software relata correlações de Spearman de 0,44 para o Claude e 0,50 para desenvolvedores, junto com estimativas do modelo comprimidas. Bom desempenho em ranqueamento não estabelece calibração em horas. Fonte. ↩

15. Intercom, Fin AI Agent outcomes, documentação consultada em 7 de outubro de 2026. Veja “Resolution definition” e a explicação de que pedidos posteriores de mais assistência na mesma conversa estornam a cobrança da resolução. Os exemplos trabalhados neste texto não usam os preços reais do Fin. Fonte. ↩

16. Tejal Patwardhan e colegas, GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks, 2025, apêndice A.2.1 e tabela 2. Os cenários de revisar e refazer usam premissas especificadas e omitem tratamento comparável de revisão e falha para a referência humana. Não devem ser lidos como estimativas gerais de economia no ambiente de trabalho. Fonte. ↩

17. Ralf Seifert, Richard Markoff e Matthew Spooner, How a new approach to demand planning can redefine success, I by IMD, 5 de agosto de 2024. Discute o forecast value added e a possibilidade de que uma linha de base melhor reduza a contribuição incremental de ajustes humanos. Fonte. ↩

18. Tom Cunningham e Parker Whitfill, Task Substitution and Uplift, METR, 8 de maio de 2026. Distingue o ganho em tarefas antigas, em tarefas novas e em valor, com relações derivadas sob premissas explícitas. Fonte. ↩

19. Robert S. Kaplan e Steven R. Anderson, Rethinking Activity-Based Costing, Harvard Business School Working Knowledge, 24 de janeiro de 2005. Distingue capacidade fornecida de capacidade consumida e discute as oportunidades que surgem da capacidade ociosa. Fonte. ↩

20. US Bureau of Economic Analysis, Chained-dollar estimates. Observa a não aditividade fora do ano de referência e alerta contra usar componentes como se fossem valores em dólar aditivos comuns. Fonte. ↩

21. Daron Acemoglu, Andrea Manera e Pascual Restrepo, Does the U.S. Tax Code Favor Automation?, Brookings Papers on Economic Activity, primavera de 2020. Analisa o tratamento tributário que favorece o investimento em equipamentos e software em relação ao trabalho. As estimativas históricas desse artigo não são um cálculo do tratamento tributário atual de nenhuma empresa em particular. Fonte. ↩

22. Gergely Orosz e Kent Beck, Measuring developer productivity? A response to McKinsey, The Pragmatic Engineer, 29 de agosto de 2023, especialmente a seção 4. A rejeição citada diz respeito às métricas customizadas de esforço e produção da McKinsey, não a toda forma possível de medição operacional. Fonte. ↩