Liderando times que usam IA no desenvolvimento

Nível: Sênior | Duração estimada de leitura: 36 minutos | Categoria: Trilha Sênior — Módulo 2 (IA para POs)

O time que você lidera hoje não é o mesmo de dois anos atrás

Em fevereiro de 2023, o GitHub publicou os resultados do estudo mais abrangente já feito sobre o impacto de assistentes de IA no trabalho de desenvolvimento. A pesquisa, conduzida com 95 desenvolvedores profissionais em ambiente controlado, mostrou que o grupo usando GitHub Copilot completou as tarefas designadas 55,8% mais rápido do que o grupo controle — e reportou maior satisfação com o trabalho.

Seis meses depois, um segundo estudo do NBER (National Bureau of Economic Research) com 5.000 agentes de suporte usando IA generativa mostrou ganho de produtividade de 14% em média — e 35% entre os profissionais menos experientes. A IA estava nivelando o campo de performance entre iniciantes e veteranos de uma forma que nenhuma outra ferramenta havia feito.

Em 2024, a McKinsey estimou que desenvolvedores usando ferramentas de IA completavam tarefas de documentação 50% mais rápido, geração de código novo 45% mais rápido e refatoração de código existente 30% mais rápido.

Esses números não são argumento para demitir desenvolvedores. São a descrição de uma transformação no trabalho de desenvolvimento que está acontecendo agora — e que muda radicalmente o que significa liderar um time de produto.

O PO Sênior que lidera um time onde engenheiros usam GitHub Copilot, Cursor, Claude ou qualquer outro assistente de IA está liderando um time diferente do que liderava há dois anos. As dinâmicas de estimativa mudaram. A distribuição de skills relevantes mudou. Os gargalos que o PO precisa gerenciar mudaram. Os riscos que o PO precisa monitorar mudaram.

Este módulo é sobre entender essas mudanças em profundidade — e adaptar o estilo de liderança de produto para o contexto de um time que desenvolve com IA.

Como IA muda o trabalho de desenvolvimento — e o que isso significa para o PO

Para liderar bem um time que usa IA, o PO Sênior precisa entender o que a IA muda no fluxo de trabalho de desenvolvimento — não no nível técnico profundo, mas no nível de quais tarefas aceleram, quais ficam mais complexas e quais habilidades se tornam mais ou menos críticas.

O que IA acelera significativamente:

Geração de código boilerplate: a parte repetitiva e estrutural do código — configurações, estruturas de dados, implementações padrão de APIs, testes unitários básicos — pode ser gerada em segundos por ferramentas como Copilot e Cursor. O desenvolvedor descreve o que precisa e a IA produz o esqueleto.

Explicação e documentação de código existente: entender código legado que ninguém documentou era historicamente uma das tarefas mais demoradas do desenvolvimento. IA consegue explicar o que um trecho de código faz, identificar dependências e gerar documentação a partir do código existente com qualidade razoável.

Debugging assistido: identificar a causa de um bug em um sistema complexo pode levar horas. Com assistentes de IA, o desenvolvedor descreve o comportamento inesperado, cola o trecho relevante de código e frequentemente recebe hipóteses de causa raiz em segundos — não sempre corretas, mas que aceleram significativamente o processo de investigação.

Geração de testes: escrever testes é frequentemente a tarefa que desenvolvedores mais postergam porque é tediosa. IA consegue gerar suítes de testes a partir do código de produção com cobertura razoável — o que muda o custo-benefício de testar adequadamente.

O que IA não acelera — e frequentemente complica:

Decisões de arquitetura: escolher a estrutura correta para um sistema, decidir onde traçar os limites entre módulos, avaliar trade-offs de escalabilidade e manutenibilidade — essas decisões continuam exigindo julgamento humano e compreensão do contexto específico do produto. IA pode sugerir opções, mas a avaliação das implicações a longo prazo é genuinamente humana.

Entendimento de domínio de negócio: a IA não sabe que "cliente ativo" na sua empresa significa cliente com pelo menos 3 transações nos últimos 30 dias — a menos que você explique. A tradução das regras de negócio específicas do produto para código continua exigindo que alguém entenda profundamente tanto o negócio quanto a implementação técnica.

Debugging de sistemas distribuídos complexos: bugs que emergem de interações entre múltiplos serviços, de condições de concorrência, de problemas de estado em sistemas distribuídos — esses casos ainda desafiam tanto humanos quanto IA. A complexidade do contexto frequentemente ultrapassa o que um assistente de IA consegue processar de forma útil.

Revisão crítica do código gerado pela própria IA: código gerado por IA frequentemente funciona mas tem problemas sutis de segurança, performance, manutenibilidade ou alinhamento com as convenções específicas do projeto. Revisar esse código com rigor exige habilidade técnica sólida — e, paradoxalmente, times com desenvolvedores menos experientes podem ter mais dificuldade em identificar problemas no código que a IA gerou do que em código escrito por eles mesmos.

O impacto nas estimativas e no planejamento de sprint

Uma das mudanças mais imediatas e práticas que o PO Sênior precisa gerenciar é o impacto de IA nas estimativas de desenvolvimento.

O problema da velocidade inconsistente:

Quando parte do código é gerada por IA, a velocidade de entrega se torna mais variável — não mais previsível. Tarefas de implementação simples, que antes levavam 2 dias, podem agora levar 4 horas. Mas tarefas de debugging complexo ou de decisão de arquitetura, que antes levavam 3 dias, ainda levam 3 dias — ou às vezes mais, porque o desenvolvedor gastou tempo tentando usar a IA para resolver um problema onde ela não ajuda.

O resultado é uma distribuição bimodal de velocidade: algumas histórias são completadas muito mais rápido do que a estimativa histórica, e outras levam o mesmo tempo ou mais. A média pode parecer estável, mas a variância aumenta — o que complica o planejamento de sprint.

Como adaptar o processo de planejamento:

Separe as histórias por tipo de trabalho ao estimar. Implementação nova com padrão bem definido (alta aceleração com IA), refatoração de código complexo (aceleração moderada), investigação de bug sistêmico (pouca aceleração), decisão de arquitetura (sem aceleração). Cada tipo tem um perfil de velocidade diferente em um time que usa IA.

Reduza o tamanho médio das histórias — mas não a quantidade de valor por sprint. Times com IA tendem a se beneficiar de histórias menores e mais específicas, porque a IA é mais eficaz quando a tarefa tem escopo bem definido. Uma história grande e vaga ("refatorar o módulo de autenticação") gera prompts de IA ruins e código de qualidade inferior. Uma história específica ("extrair a lógica de validação de token para um serviço separado mantendo os contratos de interface existentes") gera prompts melhores e código de qualidade superior.

O risco do "isso vai ser rápido com IA":

Uma armadilha que emerge em times que começam a usar IA é a tendência de subestimar sistematicamente tarefas que parecem simples mas têm complexidade de domínio significativa. "A IA vai gerar isso em minutos" — e gera. Mas o código gerado não considera a regra de negócio específica que está documentada apenas na cabeça do PO, não funciona com o banco de dados legado que tem peculiaridades não documentadas, ou viola uma convenção arquitetural que o time estabeleceu e que a IA não sabe que existe.

O antídoto: mais conversa de contexto antes do desenvolvimento, não menos. Paradoxalmente, times que usam IA com mais eficácia são frequentemente os que têm documentação de contexto mais rica — porque o investimento em documentar o contexto do sistema paga dividendos maiores quando um assistente de IA está lendo essa documentação para gerar código contextualmente correto.

Qualidade de código em times que usam IA: os riscos que o PO precisa monitorar

A aceleração de produção de código que IA traz tem um risco que nem sempre é visível imediatamente: degradação gradual da qualidade do código — especialmente em dimensões que não aparecem em testes automatizados.

O problema da dívida técnica acelerada:

Código gerado por IA tende a ser funcionalmente correto mas estruturalmente medíocre quando não é bem revisado. A IA otimiza para resolver o problema imediato — não para manutenibilidade a longo prazo, não para consistência com as convenções específicas do projeto, não para desempenho em edge cases que só aparecem em produção com escala.

Um estudo da GitClear publicado em 2024 analisou 211 milhões de linhas de código de projetos open source entre 2020 e 2023 e encontrou um aumento de 8,5% em code churn (código que é modificado ou revertido logo após ser escrito) desde a adoção generalizada de ferramentas de IA. A interpretação dos autores: código gerado por IA é mais frequentemente escrito de forma que precisa de revisão e correção rápida.

O PO Sênior não precisa entender o código — mas precisa entender quando o time está acumulando dívida técnica de forma acelerada e garantir que o processo de revisão de código (code review) está sendo levado a sério, mesmo quando o código foi gerado pela IA e "parece funcionar".

Indicadores de qualidade que o PO deve acompanhar:

Frequência de bugs em produção por sprint: se a taxa de bugs aumentou depois da adoção de ferramentas de IA sem um aumento correspondente na velocidade de entrega, é sinal de que qualidade está sendo sacrificada por velocidade.

Tempo médio de resolução de bugs: se está aumentando, pode indicar que o código está ficando mais difícil de entender e depurar — um sinal clássico de dívida técnica acumulando.

Coverage de testes: irônico, mas times que usam IA para gerar código às vezes negligenciam os testes porque "a IA também pode gerar os testes depois". Testes adicionados retroativamente frequentemente têm qualidade inferior a testes escritos de forma test-driven.

Feedback do time sobre manutenibilidade: nas retrospectivas, a pergunta "o código que estamos entregando está ficando mais fácil ou mais difícil de modificar?" revela tendências de qualidade que as métricas quantitativas podem não capturar.

A nova distribuição de skills — e o que fazer com ela

IA muda quais habilidades são mais valiosas no desenvolvimento de software — e essa mudança tem implicações diretas para como o PO Sênior pensa sobre composição de time, desenvolvimento de pessoas e processos de trabalho.

Skills que ficam mais valiosas com IA:

Capacidade de especificar problemas com precisão: a eficácia de um assistente de IA é diretamente proporcional à qualidade da especificação que recebe. Desenvolvedores que conseguem articular com precisão o que precisam — o problema, o contexto, as restrições, as convenções — extraem muito mais valor das ferramentas de IA do que os que fazem prompts vagos.

Essa habilidade — que na prática é muito próxima da habilidade de escrever boas User Stories — se torna um diferencial de produtividade entre desenvolvedores. Times de produto que investem em ensinar os desenvolvedores a fazer prompts de qualidade estão investindo em produtividade de código.

Julgamento crítico sobre outputs de IA: a capacidade de avaliar se o código gerado por IA é correto, seguro, manutenível e alinhado com as convenções do projeto é uma habilidade que requer entendimento técnico sólido e conhecimento profundo do domínio do sistema. Ironicamente, essa habilidade é mais difícil de desenvolver quando você usa IA desde o início — porque você nunca aprendeu os padrões que a IA deveria seguir.

Pensamento sistêmico e de arquitetura: se IA cuida da implementação de detalhes, o diferencial humano se desloca para o nível acima — entender como os sistemas se conectam, como as decisões de hoje afetam a flexibilidade de amanhã, onde os trade-offs de arquitetura estão. Essa habilidade cresce em valor à medida que IA assume tarefas de implementação.

Skills que perdem relevância relativa:

Memorização de sintaxe e APIs: saber de memória a sintaxe correta de uma função, os parâmetros de uma API ou as opções de uma biblioteca era uma habilidade diferencial. Com IA, essa memorização tem valor marginal — qualquer desenvolvedor pode obter essa informação instantaneamente. O conhecimento que importa é o conceitual, não o sintático.

Escrita de código boilerplate: a parte mais mecanicamente repetitiva do desenvolvimento — que historicamente exigia tempo significativo mesmo de desenvolvedores experientes — é agora uma tarefa de baixo valor quando há IA disponível.

A implicação para o PO na hora de definir critérios de aceitação e escopo:

Quando o time usa IA no desenvolvimento, a qualidade das User Stories e dos critérios de aceitação tem impacto ainda maior na qualidade do código entregue. Uma história vaga gera um prompt de IA vago, que gera código vago, que gera bugs e retrabalho.

O investimento em refinamento de qualidade — histórias bem escritas, critérios de aceitação testáveis, contexto de domínio documentado — tem ROI maior em times que usam IA do que em times que não usam.

Os desafios culturais de times que usam IA

A adoção de IA em times de desenvolvimento não é apenas um processo de implementação de ferramenta. É uma transformação cultural que gera resistências, ansiedades e dinâmicas novas que o PO Sênior precisa entender e navegar.

Resistência por medo de obsolescência:

Uma parcela dos desenvolvedores — especialmente os mais seniores com carreiras longas construídas em expertise de implementação — experimenta a adoção de IA como uma ameaça existencial à relevância profissional. "Se a IA escreve o código, para que me precisam?"

Essa ansiedade, quando não endereçada, se manifesta como resistência passiva à adoção das ferramentas — o desenvolvedor experimenta formalmente mas não integra de verdade no fluxo de trabalho — ou como comportamento defensivo: supervalorizar as limitações da IA e resistir a qualquer argumento sobre sua eficácia.

Como o PO Sênior navega isso: não ignorando a ansiedade — reconhecendo-a. E reposicionando a narrativa: IA não substitui o desenvolvedor sênior que tem julgamento técnico profundo, que entende o domínio de negócio, que toma decisões de arquitetura e que mentora o time. Substitui a parte do trabalho que nunca deveria ter sido o diferencial de um profissional sênior de qualquer forma — a escrita mecânica de código boilerplate.

Dependência excessiva e atrofia de habilidades:

O risco oposto é o desenvolvedor — especialmente o menos experiente — que adota IA com entusiasmo mas sem os guardrails necessários e começa a entregar código que não entende completamente. Ele aceita o output da IA sem revisar criticamente, porque não tem o repertório técnico para identificar os problemas.

Isso é particularmente problemático para o desenvolvimento profissional de juniores: aprender a programar através de geração de código por IA sem entender os fundamentos é análogo a aprender a cozinhar pedindo delivery e observando o entregador.

Como o PO Sênior contribui para esse gerenciamento: garantindo que o processo de code review continue rigoroso — especialmente para código gerado por IA — e apoiando a criação de espaços onde desenvolvedores menos experientes podem fazer perguntas sobre o código que a IA gerou sem se sentir julgados por não entender imediatamente.

A síndrome do "funciona, não mexe mais":

IA pode gerar código que passa todos os testes e funciona corretamente, mas que é difícil de manter, difícil de entender e difícil de modificar quando os requisitos mudarem. A tentação de "deploiar e não tocar mais" é maior quando o código foi gerado por IA — porque qualquer modificação exige entender código que ninguém realmente escreveu e internalizou.

Esse padrão, multiplicado ao longo do tempo, cria sistemas cada vez mais opacos e frágeis — exatamente o oposto do que times de alta performance precisam.

A dinâmica de dois pesos entre os que usam e os que não usam:

Em times onde a adoção de ferramentas de IA não é uniforme, criam-se dinâmicas de percepção difíceis de gerenciar. O desenvolvedor que usa Copilot e entrega 3 histórias por sprint versus o que não usa e entrega 1,5 — a diferença de velocidade aparente pode gerar atrito mesmo que o desenvolvedor mais rápido esteja criando mais dívida técnica.

A padronização das ferramentas — com processo claro de onboarding, de uso esperado e de guardrails de qualidade — previne essa dinâmica de fragmentação do time.

Novos rituais para times que desenvolvem com IA

Times que usam IA no desenvolvimento se beneficiam de ajustes nos rituais de produto e engenharia que reconhecem as novas dinâmicas de trabalho.

Prompt review como parte do refinamento:

Para histórias complexas onde IA vai ser usada no desenvolvimento, incluir no refinamento uma discussão sobre como a história seria descrita para um assistente de IA: qual é o contexto mínimo necessário, quais são as restrições que precisam ser explicitadas, quais são os exemplos que ajudariam a IA a gerar código mais relevante?

Essa discussão tem dois benefícios: melhora a qualidade do código gerado e frequentemente revela ambiguidades na história que não teriam sido identificadas de outra forma.

AI output review como etapa explícita no definition of done:

Além dos critérios usuais de done (testes passando, code review aprovado, deploy em staging), adicionar explicitamente "revisão humana de todo código gerado por IA" como critério. Não basta passar nos testes. O desenvolvedor precisa entender o código que está entregando — independentemente de quem (ou o quê) o escreveu.

Retrospectiva de IA quinzenal:

A cada dois ciclos de sprint, uma retrospectiva específica sobre o uso de IA no desenvolvimento: o que funcionou bem? Onde a IA criou mais atritos do que ajudou? Quais tipos de tarefa se beneficiam mais? Quais prompts produziram os melhores resultados? Esse ritual cria aprendizado coletivo sobre como usar as ferramentas de forma mais eficaz — e distribui o conhecimento que hoje está concentrado nos que as adotaram primeiro.

Pair programming humano-IA com revisão coletiva:

Periodicamente, o time faz uma sessão de pair programming ao vivo onde um desenvolvedor usa IA para implementar uma feature enquanto o time observa e comenta — tanto sobre o código produzido quanto sobre a qualidade dos prompts usados. É uma forma eficaz de nivelar as práticas e criar um vocabulário comum sobre "bom uso de IA" no contexto específico do time.

Propriedade intelectual e considerações éticas que o PO não pode ignorar

Liderar times que usam IA no desenvolvimento traz responsabilidades que vão além da gestão de processo e qualidade. Existem questões de propriedade intelectual e ética que o PO Sênior precisa ter clareza — não apenas para proteger o produto, mas para orientar o time com coerência.

Propriedade intelectual do código gerado por IA:

Existe debate jurídico em andamento sobre a propriedade do código gerado por assistentes de IA. Em geral, o código gerado por IA é tratado como produção do desenvolvedor que o gerou — mas com nuances importantes. Algumas ferramentas de IA, como o GitHub Copilot em suas versões mais antigas, geravam código que às vezes era idêntico ou muito próximo de código presente no dataset de treinamento (código open source com licenças variadas). Isso cria um risco potencial de violação de licença em produtos comerciais.

O PO Sênior que lidera um time que usa IA precisa garantir que a empresa tem clareza sobre a política de uso das ferramentas aprovadas e que o time entende as obrigações de revisão do código gerado — especialmente em partes do sistema que são particularmente sensíveis do ponto de vista de propriedade intelectual.

Dados de cliente em prompts de IA:

Um risco prático que emerge rapidamente em times que usam IA no desenvolvimento: desenvolvedores que fazem prompts incluindo dados reais de produção para "ilustrar o problema". "Aqui está um exemplo de registro que está causando o bug: [dados reais de usuário]." Esses dados enviados para APIs externas de IA podem violar LGPD, contratos com clientes enterprise, políticas de segurança da empresa.

A política de uso de ferramentas de IA no time precisa ser explícita sobre isso: dados de produção nunca entram em prompts sem anonimização. Dados sintéticos ou anonimizados sim. Dados reais de usuário, nunca.

A questão da transparência com os usuários:

Quando o produto usa IA para tomar ou influenciar decisões que afetam o usuário — recomendações, triagem, personalização, avaliação — existe uma expectativa crescente (e em alguns casos, regulatória) de que o usuário seja informado. "Este conteúdo foi personalizado por IA" ou "Esta recomendação é baseada em análise automática do seu histórico."

O PO que lidera times construindo features de IA precisa incluir na definição de done a pergunta: o usuário sabe que IA está sendo usada aqui? E tem mecanismo de opt-out se assim quiser?

Medindo a performance do time na era da IA

As métricas de performance de time precisam ser calibradas para o contexto de uso de IA — porque as métricas tradicionais podem tanto subestimar quanto superestimar a real performance.

O que não funciona como métrica principal:

Story points por sprint: se IA acelera a implementação de histórias simples mas não muda o tempo de histórias complexas, o time pode parecer mais rápido sem ter entregado mais valor real. Além disso, inflação de story points — estimativas maiores porque a IA "vai ser rápida, então deixa a história com mais pontos para não ter pressão" — distorce completamente a métrica.

Linhas de código: sempre foi uma métrica ruim. Com IA gerando código, fica ainda pior — times que usam IA mais irresponsavelmente podem ter mais linhas de código com menos valor.

O que funciona:

Impacto em métricas de produto: features entregues que moveram as métricas que deveriam mover. Esse é o norte que não muda independentemente de como o código foi produzido.

Cycle time: tempo médio entre o início do trabalho em uma história e o deploy em produção. Essa métrica captura tanto a velocidade de implementação (onde IA ajuda) quanto a qualidade do processo (histórias que voltam por bugs têm cycle time maior).

Change failure rate: percentual de deploys que resultam em incidentes ou rollbacks. Se IA está gerando mais código de qualidade inferior, essa métrica vai piorar — mesmo que o time pareça mais rápido no curto prazo.

Developer experience: como o time avalia sua satisfação com o processo de desenvolvimento, com as ferramentas disponíveis e com a qualidade do que está construindo. Essa métrica qualitativa — coletada em retrospectivas ou surveys — captura dimensões que nenhuma métrica quantitativa consegue.

Onde aprofundar

Livros e leituras essenciais:

Software Engineering at Google, de Titus Winters, Tom Manshreck e Hyrum Wright. Publicado gratuitamente pelo Google, é o guia mais detalhado disponível sobre como uma das maiores organizações de engenharia do mundo pensa sobre qualidade, processos e cultura de desenvolvimento. A seção sobre code review é especialmente relevante no contexto de times que usam IA.

An Elegant Puzzle, de Will Larson. Escrito por um engineering manager experiente no contexto de startups e scale-ups. Os capítulos sobre como sistemas de equipe funcionam, sobre o papel de líderes técnicos e sobre como gerenciar a transição entre estágios de crescimento têm aplicação direta para POs que lideram times com IA.

The Pragmatic Programmer, de David Thomas e Andrew Hunt (edição atualizada 2019). Um clássico que ganhou nova relevância na era da IA — especialmente as seções sobre as responsabilidades do desenvolvedor em relação ao código que entrega, sobre automação e sobre como manter o julgamento humano no centro mesmo quando ferramentas assumem tarefas.

Para entender o impacto de IA em times de desenvolvimento:

Relatório anual State of DevOps (DORA) — publicado pelo Google. O relatório mais abrangente sobre as métricas de performance de times de engenharia de software. Inclui análise crescente do impacto de ferramentas de IA nas quatro métricas-chave de DevOps (deployment frequency, lead time, change failure rate, time to restore).

GitClear Developer Productivity Report (anual) — análise de dados reais de repositórios sobre o impacto de IA na qualidade do código. Perspectiva mais crítica do que os relatórios dos próprios fornecedores de ferramentas de IA.

Relatório de Pesquisa do GitHub sobre Copilot — a série de estudos publicada pelo GitHub sobre produtividade, satisfação e qualidade de código em times que usam Copilot. Parcial (o GitHub tem interesse em mostrar resultados positivos), mas com metodologia razoavelmente rigorosa.

Certificações e programas:

Team Topologies Practitioner — certificação baseada no livro Team Topologies de Skelton e Pais. Especialmente relevante para POs que estão pensando em como reorganizar a estrutura de times para maximizar eficácia no contexto de desenvolvimento com IA.

Engineering Leadership no Reforge — mais voltado para engineering managers, mas com material de alta relevância para POs Sênior que lideram a interseção entre produto e engenharia.

Conclusão

Liderar um time que usa IA no desenvolvimento é fundamentalmente diferente de liderar um time que não usa — não apenas em processos e métricas, mas em cultura, em expectativas, em riscos e em oportunidades.

O PO Sênior que entende essas diferenças em profundidade consegue fazer algo que poucos conseguem: amplificar os benefícios reais da IA no desenvolvimento — velocidade de iteração, redução de trabalho mecânico, nivelamento de produtividade — enquanto gerencia ativamente os riscos — dívida técnica acelerada, atrofia de habilidades, dependência excessiva, degradação de qualidade.

Esse PO não é técnico. Mas entende o suficiente sobre o trabalho de desenvolvimento para fazer as perguntas certas, definir os processos certos e criar a cultura certa para que o time use IA de forma que torna o produto melhor — não apenas mais rápido.

No último módulo desta trilha, vamos fechar o ciclo com a perspectiva mais elevada possível: como o PO Sênior constrói produtos com IA — não apenas como usa IA para construir produtos. A diferença entre as duas perspectivas é o que separa o PO que sobreviverá à próxima década do que ficará obsoleto nela.