Andrew Ng, fundador do Google Brain, deu uma entrevista que devia ser leitura obrigatória pra quem toca operação — e não só pra quem programa.
A ideia em uma frase
Quando criar software fica 10 a 100 vezes mais rápido, o código deixa de ser o gargalo. O freio passa pra todo o resto da operação.
“Quando escrever software fica 10 ou 100 vezes mais rápido, não é só o produto que vira gargalo — praticamente todo o resto vira gargalo.”
É um detalhe que parece técnico, mas é puramente de gestão.
Onde o gargalo foi parar
Ng deu exemplos concretos do que acontece quando a engenharia dispara na frente e o resto fica pra trás:
- Marketing: os times correm atrás pra entender o que a engenharia já entregou — porque o ritmo de features explodiu.
- Jurídico: antes, um produto levava três meses pra ficar pronto e esperar uma semana pelo aval jurídico era tranquilo. Agora você constrói em um dia e a mesma semana de espera vira um gargalo de compliance.
- Design e governança: entram na fila como os próximos pontos de estrangulamento.
A imagem é clara: você troca o motor do carro por um de avião, mas mantém as rodas, o câmbio e o freio antigos. Não adianta. A velocidade nova expõe tudo que ficou velho ao redor.
Por que isso importa para negócios
Aqui está o erro que vejo todo dia: a empresa coloca IA em uma área, ela acelera, e a liderança comemora. Só que o resultado final não muda — porque o gargalo apenas andou pro próximo elo da cadeia.
Acelerar uma área isolada não resolve. O gargalo só muda de lugar.
Quem ganha de verdade não é quem compra mais uma ferramenta. É quem olha o processo inteiro e pergunta: agora que esta etapa ficou instantânea, qual é o novo ponto mais lento — e como eu redesenho o fluxo em volta dele?
Como aplicar
A resposta de Ng não é “contrate um exército de especialistas”. É o contrário:
- Monte times pequenos. De 1 a 10 pessoas, não departamentos inteiros em silos.
- Priorize generalistas de alto contexto. Gente que entende o negócio de ponta a ponta e usa IA pra cobrir funções que não são a especialidade dela — um engenheiro que faz o primeiro rascunho da copy, por exemplo.
- Dê guardrails largos, não roteiros estreitos. Defina os limites e deixe o time correr dentro deles, com autonomia pra construir, subir e decidir.
- Ataque o gargalo, não a área que você mais domina. Depois de acelerar uma etapa, encontre o novo elo mais lento antes de comprar a próxima ferramenta.
A minha leitura
O que o Ng está descrevendo não é uma tendência de engenharia — é uma tendência de desenho de operação.
A IA tornou a execução barata. Quando a execução fica barata, o valor migra pra duas coisas: decidir o que fazer e coordenar o resto da máquina pra acompanhar. Quem continua otimizando só a parte que já era rápida está polindo a roda enquanto o resto do carro engasga.
A pergunta que fica pra você: na sua operação, qual é a etapa que já está rápida — e em qual elo ela trava logo depois? É ali que está o seu próximo ganho, não numa ferramenta nova.
Fonte do vídeo que originou esta análise: @AnatoliKopadze no X. As falas referidas são as ditas por Andrew Ng na própria entrevista.