IA muda os gargalos do trabalho, não os elimina

Da agilidade à adoção de IA

O autor afirma que a IA está obrigando pessoas e organizações a reconsiderar quem são, o que fazem, que impacto conseguem produzir e como são percebidas. Nesse contexto, ele descreve uma mudança de foco profissional: de seu trabalho anterior com escalabilidade e agilidade para ajudar organizações a passar da atividade ao impacto e a construir formas de operação nativas de IA.

A tese central é que muitos padrões desenvolvidos ao longo de anos para melhorar ciclos de desenvolvimento, fluxo de trabalho e funcionamento organizacional também se aplicam à adoção de IA. O autor identifica uma semelhança entre o “teatro da IA” e o teatro associado a transformações ágeis: iniciativas motivadas por entusiasmo, pressão do mercado ou medo de ficar para trás podem produzir muita atividade sem resolver problemas relevantes. Segundo ele, a adoção deveria partir de uma dor dispendiosa ou de uma oportunidade concreta, e não apenas do FOMO - o receio de ficar de fora.

O gargalo, não a atividade mais visível

O autor se apresenta metaforicamente como um “encanador” organizacional: alguém que encontra pontos de bloqueio, gargalos e desordens em sistemas de trabalho. Ele relata ter aplicado práticas e estruturas de agilidade, fluxo, Kanban e gestão baseada em evidências em diferentes contextos, incluindo organizações de engenharia, negócios e uma empresa de biotecnologia que usa IA.

Para explicar seu método, recupera um caso de cerca de 2010 em uma grande empresa de tecnologia. A visualização do fluxo de ponta a ponta, por meio de diagramas de fluxo cumulativo, mostrou uma diferença de capacidade entre desenvolvimento e testes. A conclusão não foi simplesmente fazer os desenvolvedores produzirem mais, mas tratar os testes como o gargalo e subordinar o restante do trabalho a essa restrição. Entre as possibilidades citadas estavam automatizar testes, facilitar o acesso a APIs mais estáveis e melhorar a abordagem e a arquitetura de testes.

O autor diz observar situação semelhante em ciclos de desenvolvimento de software com agentes: em alguns casos, a codificação deixa de ser o gargalo - ou nunca foi o principal. Por isso, aumentar a velocidade de uma função específica pode apenas melhorar um ponto local sem elevar o desempenho do sistema inteiro. A orientação proposta é identificar a restrição dominante e organizar o trabalho em torno dela.

Atividade é mais fácil que impacto

A fonte também explica por que organizações tendem a medir atividade em vez de impacto. Métricas como linhas de código, horas trabalhadas, tarefas planejadas e concluídas, uso de tokens, frequência de uso de ferramentas e quantidade de agentes são fáceis de contar e podem funcionar como métricas de vaidade.

É possível medir resultados intermediários, como o número de funcionalidades, artigos, habilidades ou podcasts produzidos, mas medir impacto é mais difícil. O autor sustenta que equipes de produto e áreas internas precisam enfrentar essa dificuldade para entender que efeito seu trabalho realmente produz, em vez de confundir volume de atividade com valor.