IA acelera tarefas de produto, mas o trabalho só muda de lugar

O que a IA acelera de verdade

Candace Wilson, designer de produto, descreve como a IA tornou partes do seu trabalho inegavelmente mais rápidas. Na síntese de pesquisa, ela usa IA para organizar transcrições de descoberta, testes com usuários e conversas com stakeholders, extrair temas recorrentes e montar bases de apresentações. Uma síntese que levava dias às vezes sai em um dia ou menos. A responsabilidade de ler, questionar e validar o resultado continua; o que mudou é o tempo gasto em trabalho administrativo. Essa economia permite explorar mais direções, buscar lacunas e encaixar rodadas extras de teste que seriam cortadas em prazos apertados.

Protótipos codificados e o problema que se move para jusante

A equipe dela passou a criar protótipos codificados com a expectativa de que o desenvolvimento reutilizasse partes do código na produção, reduzindo a 'ciranda de telefone sem fio' dos handoffs tradicionais - diferenças de espaçamento, comportamento responsivo e detalhes de interação que se acumulam como dívida de design. Na prática, porém, os designers nem sempre tinham profundidade técnica para avaliar a estrutura do código. Páginas com milhares de linhas, fronteiras de componentes confusas e implementações que não correspondiam à intenção do design chegavam ao desenvolvimento. O gap visual de handoff foi trocado por um gap arquitetural: parte do esforço apenas migrou para o time de engenharia, que precisava interpretar, refatorar ou reconstruir o trabalho.

Para onde vai o trabalho

Wilson propõe um vocabulário para o que acontece com o esforço quando uma etapa acelera: ele pode desaparecer, encolher, mudar de forma, migrar para outra pessoa ou aparecer mais tarde. Em vez de criar cada artefato, agora se passa mais tempo direcionando a ferramenta, revisando, corrigindo e decidindo se o resultado é confiável. Um estudo longitudinal de 2026 de Annie Vella e Kelly Blincoe encontrou o mesmo padrão entre engenheiros de software profissionais: menos tempo escrevendo código, mais trabalho de dirigir, avaliar e corrigir saídas de IA - o que as pesquisadoras chamam de 'trabalho de engenharia supervisionária', e a autora, de 'babysitting'. O estudo se baseia em autorrelato, não em medição direta de tempo.

A velocidade local depende do sistema

A pesquisa DORA de 2025 sobre desenvolvimento assistido por IA mostra que a IA amplifica o sistema ao redor: fluxos fortes tornam a velocidade valiosa, fluxos fracos a transformam em atrito a jusante. O mesmo estudo associou maior adoção de IA a mais throughput de entrega, mas também a mais instabilidade - interpretado como times se adaptando à velocidade mais rápido do que os sistemas ao redor conseguem suportar com segurança. Produtividade local e produtividade do sistema não são a mesma coisa: ganhos individuais não dizem se o caminho total da ideia à produção encurtou ou se surgiu retrabalho.

O que significa 'bom o suficiente'

Uma conversa com colega levou à ideia de aceitar código mais bagunçado se a UI estiver correta, corrigindo depois de forma reativa. Wilson reconhece que isso pode fazer sentido em exploração inicial, mas rejeita como padrão universal: uma revisão visual não detecta estrutura ruim de componentes, lógica duplicada, problemas de dados ou de controle de acesso. Código rápido de gerar ficou mais lento e caro de desenterrar depois, inclusive para ferramentas de IA, que precisavam processar mais contexto a cada mudança. A resposta do time foi refatorar mais cedo, adicionar guias em Markdown e guardrails mais claros. O critério que ela propõe: o código do protótipo não precisa estar pronto para produção, mas deve ser útil para produção - fronteiras claras, peças realmente reutilizáveis, comportamento responsivo fiel à intenção do design. O grau de rigor deve depender do que o artefato vai influenciar. A DORA também rejeitou a hipótese de que entrega mais rápida tornaria a instabilidade aceitável: ela seguiu tendo efeitos negativos reais no desempenho do produto e em burnout.

O que medir

Wilson cita a atualização de 2026 da METR: o estudo anterior havia encontrado desenvolvedores open-source experientes mais lentos com ferramentas de IA de início de 2025, mas a nova pesquisa ficou difícil de interpretar porque desenvolvedores mudaram quais tarefas fazem sem IA e às vezes trabalham em outra coisa enquanto um agente roda. A METR acredita que desenvolvedores provavelmente estão obtendo mais benefício das ferramentas mais novas, mas diz que seu experimento atual não consegue medir com confiabilidade o tamanho desse benefício. A lição: 'mais rápido' fica mais difícil de medir quando o trabalho muda ao redor da ferramenta.

Conclusão

O objetivo não é desacelerar a IA - os ganhos são reais e valiosos. O desafio de liderança é garantir que o resto do sistema acompanhe: handoffs que evoluam, padrões mais claros, melhores formas de revisar, verificar e reutilizar o que a IA produz. Tratar criação mais rápida como linha de chegada é o erro. O que importa é se a velocidade leva a melhores decisões, facilita a etapa seguinte e entrega valor ao cliente sem custo em retrabalho - e saber, quando um trade-off é aceito, se é uma troca razoável ou um empréstimo contra a velocidade futura.