O novo jogo da área de tecnologia com IA
A IA torna tratável um backlog que sempre foi infinito: ticket, bug, dívida, incidente. Isso é ótima notícia. Só que, sem revisão de verdade, essa mesma velocidade vira dívida técnica escondida e incidente em produção.
Segunda de manhã, o board do time tem 340 itens abertos: bug, pedido de feature pequena, item de dívida técnica que ninguém nunca priorizou. Isso sempre foi assim, e sempre vai continuar chegando mais rápido do que qualquer time consegue fechar. Antes, esse volume era gerido no talho: os dez itens mais barulhentos da semana, o resto esperando um milagre de capacidade. Hoje a IA lê o board inteiro, agrupa duplicata, sugere severidade e já propõe o primeiro rascunho de correção pra um terço dos itens simples. O board que parecia uma montanha vira uma lista que dá pra atacar. A pergunta que decide se isso vira ganho ou vira problema não é mais "dá tempo de olhar tudo?": é "quem revisa o que a IA decidiu sozinha antes de isso virar produção?".
O jurídico pede uma lista de todas as bibliotecas de código aberto usadas no produto, com a licença de cada uma, porque um investidor vai auditar isso na due diligence de amanhã. Antes, isso era um dia cruzando arquivo de dependência com site de licença um por um. Hoje a IA lê o arquivo de dependências do projeto inteiro e devolve a lista com a licença de cada biblioteca em minutos. A lista parece completa e pronta pra anexar ao relatório. Só que ela classificou como "MIT, sem restrição" uma biblioteca que na verdade está sob uma licença com cláusula de copyleft que pode obrigar a abrir parte do seu próprio código se for redistribuído do jeito que vocês fazem. Confirmar a licença real antes de ela entrar no relatório do investidor continua sendo do time técnico revisando junto com o jurídico.
Você precisa contratar dois engenheiros seniores para o time de plataforma antes do fim do trimestre, e o volume de currículo triplicou desde que a vaga ficou remota. Antes, isso era uma semana lendo currículo um a um. Hoje a IA lê os 400 currículos, aponta os quinze mais aderentes ao perfil técnico e já sugere perguntas de entrevista específicas para cada um. A triagem que era impossível vira uma lista curta. Mas a IA valorizou anos de experiência com uma stack específica que o seu time já está migrando para longe, um sinal que só quem conhece o roadmap técnico enxerga. Decidir quem entra na entrevista final continua sendo do gestor que conhece pra onde a arquitetura está indo.
O trimestre fecha e você precisa decidir quais das vinte ideias do roadmap entram no próximo ciclo, com o CPO esperando a priorização até quinta. Antes, isso era dias cruzando dado de uso, ticket de suporte e opinião de stakeholder na mão. Hoje a IA lê tudo isso e devolve um ranking com pontuação de impacto por iniciativa. O ranking parece objetivo e pronto pra virar decisão. Só que a IA pontuou alto uma feature cujo "impacto" veio de um pedido de um único cliente grande, sem olhar que o time de engenharia já sinalizou que a base de código ali está frágil demais pra mexer sem quebrar outra coisa. Decidir o que entra no ciclo, pesando viabilidade técnica real, continua sendo seu.
Um prospect grande pergunta, na call de amanhã, se a sua plataforma suporta integração via webhook em tempo real, e o vendedor te chama de última hora pra confirmar. Antes, isso era abrir o repositório e ler a documentação técnica na correria. Hoje a IA lê o código e devolve, segura, "sim, o endpoint de webhook já suporta isso". Ela leu um endpoint que existe, mas está marcado como deprecated há dois meses e vai sair do ar no próximo release. Se o vendedor repete essa resposta pro cliente sem checar com o time técnico, a venda fecha em cima de uma promessa que não existe mais. Confirmar o que a plataforma realmente suporta, hoje, continua sendo do time que mantém o código.
Você recebeu um alerta de que o processo de faturamento automático falhou pra 40 clientes esta madrugada, e precisa de uma correção antes do horário comercial. Antes, isso era acordar alguém do time e torcer pra essa pessoa lembrar onde fica aquele script antigo. Hoje a IA lê o log de erro, propõe um patch e já teria o pull request pronto pra revisão em minutos. A correção parece pronta pra subir direto. Só que o patch da IA resolve o sintoma (o erro que apareceu no log) sem tocar na causa real, um limite de conexão simultânea no banco que só volta a estourar na próxima madrugada de pico. Aplicar a correção certa, não só a que cala o alerta, continua sendo do time que entende o sistema.
A auditoria de LGPD do trimestre exige provar que nenhum log de produção guarda CPF de cliente em texto plano, e o auditor chega amanhã. Antes, isso era um dia varrendo repositório e configuração de logging manualmente. Hoje a IA varre o código e os arquivos de configuração de logging em minutos, e aponta três serviços como conformes. Só que ela não teve acesso aos logs que já estão armazenados há dois anos no sistema de observabilidade, só ao código que os gera hoje, então o passivo real (dado sensível já guardado) continua lá, invisível pra varredura dela. Confirmar o que efetivamente está guardado, e não só o que o código atual geraria, continua sendo do time técnico junto com compliance.
O time de design pergunta se dá pra saber, ainda hoje, em qual etapa do checkout os usuários mais abandonam depois do último deploy, porque a reunião de prioridade é amanhã cedo. Antes, isso era um dia cruzando evento de analytics com log de erro na mão. Hoje a IA cruza os dois e aponta, em minutos, que o abandono se concentra na tela de pagamento. O diagnóstico parece pronto pra virar prioridade de sprint. Só que a IA cruzou os dados sem notar que metade desse abandono aconteceu numa janela de trinta minutos em que o gateway de pagamento externo caiu, um problema pontual e já resolvido, não um problema de fluxo. Decidir se isso vira prioridade de redesenho ou se já era continua sendo do time que conhece o histórico do sistema.
O board pergunta se a plataforma aguenta dobrar de tamanho em doze meses sem reescrever nada, e você tem até sexta pra responder. Antes, essa resposta vinha de uma semana de reunião entre arquitetos tentando estimar limite de capacidade. Hoje a IA lê métricas de uso, aponta os três serviços mais próximos do limite e devolve uma resposta confiante: "a plataforma aguenta, com ajuste pontual". Ela nunca viu o contrato do fornecedor de infraestrutura que expira em seis meses, nem o gargalo de banco que só aparece na Black Friday. A decisão estratégica de investir ou não numa reescrita, que o board vai bancar com orçamento real, continua sendo do CTO, não do relatório bonito.
Putz, todo time de tecnologia carrega o mesmo peso: um board de ticket que nunca zera, um monte de dívida técnica que ninguém tem tempo de atacar, e um plantão que vive apagando incêndio. Pensa comigo: e se o backlog infinito deixasse de ser infinito? A IA muda essa conta de um jeito real. Só que ela muda a conta errada se você deixar a velocidade correr sem ninguém realmente olhando o que está passando.
A ideia central desta aula. Pela primeira vez, um backlog que sempre foi maior do que a capacidade do time (bug, ticket, dívida técnica, incidente) vira algo tratável em volume: a IA triaga, propõe o primeiro rascunho de correção, resume o incidente, escreve o esboço da documentação. Isso é boa notícia de verdade. O que continua sendo do time, e ficou mais crítico justamente porque a parte mecânica sumiu, é a arquitetura, a prioridade real por trás do ticket, a avaliação de risco e a assinatura de quem manda algo pra produção. E existe um porém que esta área não pode ignorar: velocidade sem revisão de verdade vira dívida técnica invisível e incidente em produção. Esta trilha é sobre operar essa área no novo jogo, sem pagar essa conta.
01O que a IA torna tratável na área
Vamos nomear a mudança direito. Estas coisas, que sempre estouraram a capacidade de qualquer time, a IA já ataca em volume:
- Triagem de ticket em escala. Agrupar duplicata, sugerir severidade, apontar o time certo, no board inteiro, não só nos dez mais barulhentos.
- O primeiro rascunho de correção. Pra bug simples e conhecido, um pull request inicial pronto pra revisão, não pra merge direto.
- O resumo de incidente e de log. Cruzar painel de observabilidade, log de erro e histórico de deploy pra apontar o suspeito mais provável.
- O rascunho de documentação. Descrever o que um serviço faz, gerar o primeiro esboço de runbook, atualizar o que ficou desatualizado.
A questão central é simples: quando o trabalho de varrer volume fica barato, ele para de ser o gargalo. O time que só conseguia reagir aos dez itens mais urgentes da semana agora consegue atacar os trezentos. Isso é uma virada real na área. E tem um lado que exige atenção redobrada, que é exatamente o assunto da seção três.
O que muda na capacidade de atacar o backlog:
Beleza? A boa notícia é sólida. Mas ela só continua boa se a próxima seção também for verdade no seu time.
02O que continua sendo do time, e ficou mais crítico
Aqui está o que a IA não decide por você, e que passou a valer mais justamente porque a parte mecânica ficou barata:
- A arquitetura. A IA compara opções e sugere um caminho, mas ela nunca operou o seu sistema numa sexta-feira de pico. Decidir a direção estrutural continua sendo de quem vive com a consequência.
- A prioridade real por trás do ticket. Um item "de baixa severidade" pode estar bloqueando o cliente que mais paga. Isso é leitura de negócio cruzada com leitura técnica, e é sua.
- A avaliação de risco. A IA aponta o que parece explorável ou frágil. Decidir o que é crítico de verdade, no seu contexto específico, continua sendo do time.
- Quem assina o que vai pra produção. A IA propõe o patch, o pull request, o rollback. Quem aprova o merge e responde se der errado é uma pessoa. Sempre.
Repara que tudo isso é julgamento, não triagem. E julgamento é exatamente o que fica mais caro quando a triagem fica barata. O trabalho do time, daqui pra frente, mora muito mais em "isso realmente importa e é seguro subir" do que em "consegui dar conta do volume".
03O porém mortal: velocidade sem revisão vira dívida e incidente
Agora a parte que não dá pra deixar passar batido, porque na área de tecnologia ela custa muito caro. Um agente de IA consegue abrir pull requests rápido, corrigir bug pequeno, propor refatoração, em volume muito maior do que qualquer time consegue revisar com o mesmo cuidado de sempre. Isso não é hipotético: é o padrão que já se vê em times que adotaram agente de código sem redesenhar a revisão.
O mecanismo do problema é simples de enxergar e fácil de ignorar. Se a revisão de cada mudança vira um carimbo rápido, porque tem gente demais pra revisar e pouco tempo, complexidade sutil vai se acumulando sem ninguém perceber: uma dependência circular aqui, uma exceção mal tratada ali, um teste que passa mas não cobre o caso real. Nada disso quebra sozinho. O sistema continua de pé, e a dívida vai se empilhando invisível, até que um dia a combinação errada de fatores aparece em produção, e vira incidente.
Saiba mais: por que a dívida técnica gerada por agente é diferente da dívida de sempre
Toda equipe já convive com dívida técnica, isso não é novidade. O que muda com agente de código operando em volume é a velocidade de acúmulo e a dificuldade de rastrear a origem. Um humano cansado escreve um atalho ruim de vez em quando, e o padrão costuma se repetir de um jeito que o time reconhece com o tempo. Um agente pode gerar dezenas de pull requests por semana, cada um pequeno e aparentemente correto sozinho, mas a interação entre eles é o que ninguém revisou com atenção, porque revisar interação entre mudanças pequenas exige mais tempo do que revisar cada mudança isolada. O risco não está em nenhum pull request específico. Está na soma que ninguém somou. Por isso esta trilha volta a esse ponto em duas aulas mais à frente, na dívida técnica visível e na auditoria do código que você não leu: o antídoto não é desacelerar a IA, é redesenhar a revisão pra dar conta do volume novo.
04O mapa desta trilha
Esta aula foi o quadro geral. As próximas descem no concreto, uma peça de cada vez:
- Conectar a IA ao estado do seu sistema, sem vazar segredo nem credencial.
- O backlog que se tria sozinho, com você decidindo a prioridade real.
- A dívida técnica que ninguém enxergava, virando visível e priorizável.
- Incident response com copiloto, sem perder a causa raiz de vista.
- A decisão de build versus buy, com critério, não com euforia.
- A auditoria do código que você não leu, antes de ele virar seu.
- E, no fim, o seu OS da área de tecnologia: os fluxos e critérios que ficam trabalhando por você.
Cada uma pega um pedaço real do trabalho da área e o redesenha com a IA dentro, sem perder o controle de vista. Vamos?
Faça agora
Pegue uma entrega técnica recente da sua área, a sua tarefa real ou outra (um pull request, um incidente resolvido, uma decisão de arquitetura pequena). Divida numa folha em duas colunas:
- Mecânico (o que a IA faria por você): triagem, primeiro rascunho de correção, resumo de log, esboço de documentação.
- Julgamento (o que continua sendo do time): a decisão de arquitetura por trás, a prioridade real considerando o negócio, a avaliação de risco, quem assina o merge ou o deploy.
Agora olhe a proporção. Quanto do tempo do time foi pra coluna da esquerda, no ritmo de hoje? Esse é o tempo que esta trilha devolve, pra reinvestir na coluna da direita, que é onde mora o julgamento que ninguém mais faz por vocês.
Pratique
1. No novo jogo da área de tecnologia, o que a IA torna tratável pela primeira vez em volume?
2. Por que velocidade sem revisão de verdade é especialmente perigosa quando um agente de IA gera muitos pull requests?
3. Por que a área de tecnologia não pode tratar a revisão humana como opcional, mesmo com a IA acelerando o trabalho mecânico?
Para o quadro
Sobre o que ficou tratáveltriagem em volume, primeiro rascunho de correção e resumo de incidente. O board deixa de ser montanha.
Sobre o perigo da velocidadenada quebra sozinho no caminho. A dívida se empilha invisível até a combinação certa estourar em produção.
Sobre a revisãoa IA acelera o rascunho. A revisão é o que garante o que sobe, e a assinatura final é sempre humana.
Valeu pelo feedback. Isso ajuda a afiar a próxima aula.