Software e IA para quem aprova, contrata e responde pelo resultado

0:00Bem-vindos a esta análise executiva. Hoje, o objetivo é transformar completamente a forma como as lideranças gerenciam e aprovam projetos de software na era da inteligência artificial.

0:12Historicamente, a gente sabe que o foco sempre esteve em medir a digitação de código, não é mesmo? Aquele volume puro. Mas a verdade é que o jogo virou. O verdadeiro desafio e onde o investimento real precisa estar agora, mudou de lugar.

0:25O foco passa a ser gerenciar resultados, ter uma clareza absoluta nas exigências e, principalmente, fazer uma revisão estratégica de tudo que é produzido. Bom, vamos mergulhar nesse roteiro. Os seis pilares essenciais que vamos explorar hoje são o gargalo da revisão, como pedir bem, onde o software vive, as escolhas de arquitetura, como ler números de forma crítica e o planejamento.

0:50Começando pelo pilar número 1, o gargalo da revisão, ou seja, a transição da digitação para a decisão. A primeira grande mudança de paradigma no cenário atual é bem impactante.

1:02A inteligência artificial reduziu drasticamente o custo e o tempo de escrever código. Para ter uma ideia, a pesquisa da Sonar aponta que, em janeiro de 2026, 42% do código commitado, que é aquele jargão técnico para o código oficialmente salvo e registrado no repositório da equipe, já vai nascer gerado ou assistido por IA.

1:21O que isso significa na prática? Que o gargalo se moveu inteiramente para a etapa de revisão humana. Então, continuar pagando por volume de produção hoje é exatamente a mesma coisa que pagar duas vezes pela mesma revisão, que acaba ficando totalmente represada.

1:35Pensa bem, a métrica antiga focava em rastrear aquele volume gigante de linhas e tarefas produzidas. Mas, no fundo, isso mede apenas o esforço. A nova realidade exige algo diferente.

1:46Exige medir o tempo exato até a entrega chegar de fato ao cliente, e também quantas dessas entregas precisaram ser desfeitas. É exatamente aqui que entra aquele conceito famoso de vibe coding.

1:57Os modelos de IA escrevem o código bruto, enquanto os humanos dirigem pela intenção, conversam com a ferramenta e focam 100% da energia na revisão criteriosa do que voltou. Por conta disso, a primeira decisão prática para quem aprova orçamentos é mandar uma regra clara, exigir a razão entre as entregas que realmente chegaram ao cliente e as mudanças que precisaram ser desfeitas.

2:18É super importante entender que qualquer painel gerencial que fique exibindo só o volume de linhas produzidas é, no nosso cenário atual, uma gigantesca ilusão de produtividade. Avançando para o pilar número 2, como pedir bem.

2:33Aqui a gente fala de clareza, contexto e verificação. A mecânica de controle real exige saber exatamente como solicitar trabalho aos modelos. E nessa hora, o contexto é absolutamente vital.

2:45Ele é aquele pacote que reúne os arquivos autorizados, os exemplos, as restrições exclusivas e aquelas decisões que a empresa já tomou no passado. A falta desse contexto é, sem dúvida nenhuma, o erro mais caro possível. Sabe por quê?

3:00Porque sem material de referência, a IA simplesmente devolve respostas genéricas, baseadas na média do que existe na internet. E o resultado disso? Ciclos infinitos de rescritas e muito dinheiro perdido.

3:12Então, antes que qualquer instrução seja sequer escrita, três dimensões são inegociáveis. Para clareza, exige-se o resultado esperado detalhado, tudo por escrito. Para o contexto, é obrigatório apresentar os arquivos e as restrições da casa.

3:26E para verificação, precisa ter uma demonstração claríssima de que o resultado foi atingido. É isso que garante que o trabalho não avance às cegas para depois chegar na mesa da diretoria como um tremendo atraso disfarçado.

3:38Para fechar essa etapa de controle, aqui vai a política definitiva e prática, que basicamente substitui aquelas listas gigantes de regras. Seja para a equipe interna ou para fornecedores externos, a regra única para pedidos exige declarar sempre cinco coisas.

3:53O repositório, o branch, que é uma linha paralela e isolada de trabalho, fundamental para não quebrar o código principal, o ambiente, o problema exato que precisa ser resolvido e o critério de aceite. Simples assim, mas faz toda a diferença.

4:06Vamos para o pilar número 3, onde o software vive, a rota do segredo. Olha, assinar um contrato de tecnologia sem definir quem tem acesso ao sistema que está no ar é literalmente como entregar um cheque em branco.

4:19O software sobe por degraus que são muito bem definidos, sai do computador de quem desenvolve, vai para o ambiente compartilhado da equipe, sobe para o ensaio, que o pessoal de tecnologia chama de staging, que é aquele espaço seguro de teste final, e chega na produção.

4:34Produção é onde o cliente final interage com o produto para valer. E o detalhe assustador é que o custo e o impacto de um erro se multiplicam violentamente a cada degrau que a gente sobe. E aqui é preciso fazer uma distinção muito clara sobre segurança.

4:46Um segredo é uma informação vital que concede acesso tipo senhas de banco de dados e precisa obrigatoriamente estar trancada em um cofro digital. Isso é muito diferente de uma variável de ambiente, que apenas informa os endereços que mudam entre os degraus.

5:01Segredos nunca, em hipótese alguma, devem estar soltos em chats ou planilhas. Pegar atalhos perigosos, como conectar computadores de desenvolvimento direto ao banco de dados de produção para fazer um teste rápido, coloca dados reais de clientes em um risco imenso e desnecessário.

5:17Então, a decisão prática aqui se traduz em cláusulas de contratos super estritas. As lideranças precisam exigir documentação clara sobre quem tem acesso descrita no ambiente de produção, qual é o registro e a validade desse acesso e, muito importante, instituir uma rotina rigorosa de troca de credenciais toda vez que um membro da equipe sai do projeto.

5:40Sem isso, não existe auditoria possível, ainda mais considerando a rotatividade natural das equipes. Entrando no pilar número 4, escolhas e custo de reverter. Vamos falar de stack, arquitetura e repositório.

5:54É essencial dominar essa separação técnica, que frequentemente se confundem de um jeito absurdo. Stack é simplesmente a lista das tecnologias e linguagens que foram escolhidas. Já arquitetura é o desenho estrutural da coisa, quem chama quem, sob qual contrato e qual é o plano de contingência caso uma parte do sistema caia.

6:14Também existe uma confusão enorme entre monorepo, que é o local físico onde os códigos vivem juntos, e monólito, que é o que dita como o sistema sobe inteiro para a produção. O ponto principal é que apenas comprar a tecnologia do momento ou reorganizar arquivos não resolve, de jeito nenhum, falhas no desenho da arquitetura. Isso nos leva a uma pergunta implacável que deve ser feita ao avaliar qualquer proposta. Quanto custa desfazer cada item desse orçamento? A facilidade de reversão é o que define o tamanho da chamada dívida técnica. Sabe aquele atalho tentador que resolve o problema rápido hoje, mas cobra juros compostos até a mudança no futuro? É isso. Se desfazer uma escolha técnica custa muito caro.

6:55Essa decisão requer uma avaliação e a aprovação bem criteriosa de um comitê. E não só uma escolha rápida feita pela equipe durante o desenvolvimento diário. Chegamos ao pilar número 5. Como ler números. Sobrevivendo a hype da IA.

7:11Adotando uma lente bem analítica agora, a regra de ouro é entender que as informações sobre produtividade chegam em três níveis distintos de evidência. E claro, eles não têm o mesmo peso. O nível 1, que é o mais forte e confiável, é a telemetria.

7:26Aquele registro automatizado de atividades reais, sempre junto com ensaios rigorosamente controlados. O nível 2 são as declarações comerciais que os próprios fornecedores fazem sobre os produtos deles. E o nível 3?

7:40Bom, são aqueles números soltos, sem uma fonte localizável, sem amostra, sem data e sem método claro, Esses números simplesmente não devem embasar nenhum tipo de investimento. Quando a gente analisa dados reais da indústria, a complexidade fica bem evidente.

7:54Por exemplo, o relatório da Faros AI observou um aumento de 242,7% nos incidentes por pedido nos períodos de maior adoção de AI. A Anthropic relatou que 80% do código foi integrado via modelo.

8:09Mas, olha o detalhe, eles incluíram uma ressalva de que esse número superestima o ganho real. É um detalhezinho que costuma sumir magicamente nas reuniões executivas. E uma pesquisa feita pela New Relic mostrou que 82% dos líderes relataram falhas em produção ligadas a códigos gerados por IA.

8:26Fica muito claro que medir apenas o consumo da ferramenta não equivale de forma alguma ao observar o retorno real sobre o investimento. Por isso, a decisão prática, inegociável ao lidar com novas tecnologias é estabelecer uma linha de base.

8:40É absolutamente mandatório medir a entrega ao cliente e volume de retrabalho especificamente nas quatro semanas anteriores à adoção da ferramenta. Sem essa medida de comparação prévia, nenhum, repito, nenhum ganho de produtividade prometido pela IA tem como ser comprovado ou validado de fato.

8:59E, finalmente, nosso pilar número 6, planejamento e capacidade desejada. Participar do planejamento desde o primeiríssimo momento é a única forma de evitar que todo aquele peso do retrabalho recaia lá na etapa de revisão, que é quando tudo já custa muito mais caro.

9:15O cenário da distribuidora Aurora ilustra isso perfeitamente. Quando foi solicitado um simples painel de estoque, que é um pedido focado basicamente em telas, o resultado exigiu três demoradas rodadas de ajuste.

9:27Porém, quando mudaram a abordagem para nomear a capacidade desejada, ou seja, exigir saber em que dia cada centro fica sem produto, a entrega fluiu e fechou perfeitamente logo na primeira rodada. A diferença de abordagem aí é estrutural.

9:41Quando se pede uma funcionalidade isolada, a equipe recebe apenas telas para desenhar, não toma decisões estruturais com autonomia e a correção vira um gargalo imenso só no fim do projeto.

9:51Já ao planejar por capacidade desejada, a equipe recebe um resultado claro e observável. Isso permite que eles operem autonomamente dentro de limites bem definidos, enquanto correções vão aparecendo de forma controlada durante entregas pequenas.

10:05Para consolidar todo esse mapa que traçamos hoje, aqui estão as cinco palavras vitais para se ter sempre em mente. Produção, que é o ambiente que cobra em receita, contexto, o material que desaparece sem ninguém notar, reversibilidade, o custo de desfazer que dita quem é que decide, dívida técnica, o atalho que cobra juros implacáveis e linha de base sem a qual nenhum ganho se sustenta na vida real.

10:29Tudo isso deixa uma provocação final bem importante para a gente refletir. O orçamento aprovado hoje continua financiando e medindo apenas o esforço de digitação ou já está realmente orientado para garantir capacidades de negócios e resultados reais com bem menos necessidade de revisão no final?

0:00Imagina a seguinte cena que, assim, aposto que muita gente que acompanha nossas análises já viveu. Tem um executivo com uma proposta de orçamento pesadíssima na mesa. O famoso cheque em branco, né? Exatamente. E o fornecedor de tecnologia ali, na frente dele, está prometendo adotar novas ferramentas de inteligência artificial para os desenvolvedores da empresa.

0:24O grande argumento de venda. Um ganho gigantesco, tipo quase inacreditável, de produtividade, e tudo isso totalmente baseado no volume de linhas de código que essa IA vai girar. É, e a tensão no ar nessas horas é palpável. Nossa, demais!

0:41Porque, pense bem, se a caneta aprovar esse orçamento, a pessoa corre o risco de pagar uma fortuna por algo puramente cosmético. Mas, se recusar, existe aquele pavor de deixar a empresa inteira para trás na corrida do mercado, sabe?

0:54É o medo de perder o bonde, com certeza. E é exatamente por isso que o nosso mergulho profundo de hoje vai direto no centro dessa decisão.

1:02A gente vai dissecar o capítulo Fundamentos do curso gratuito chamado Software e IA para Executivos do Alexandre Caramaschi. Isso aí! A nossa missão hoje é armar quem senta nessa cadeira de liderança com o vocabulário e o raciocínio exatos para aprovar, contratar e cobrar engenharia de software na era da IA.

1:22E, claro, sem cair nessas armadilhas de orçamento. E, olha, o ponto de partida para desarmar essas armadilhas é um dado lá de janeiro de 2026. A fonte traz que, naquele momento, 42% do código commitado, e só para alinhar, commitado é aquele código que é registrado oficialmente no repositório do time, tá?

1:41Então, 42% já nascia gerado ou assistido por inteligência artificial. 42%? É quase metade? Pois é. Isso muda absolutamente toda a natureza do problema que o executivo precisa resolver.

1:56Porque quando quase metade do que uma empresa produz e código vem de uma máquina, a liderança precisa parar de olhar para aquela métrica antiga de tipo esforço de digitação. Tá, peraí, vamos desempacotar isso. Porque se a IA já está girando tanto código, o que acontece com a métrica tradicional de volume produzido?

2:15Fica inútil. Fica não só inútil, mas muito perigosa. A fonte mostra que o gargalo saiu da digitação. É tipo, para usar uma analogia do dia a dia, medir produtividade por linhas de código escritas hoje seria como adicionar uns 50 caixas rápidos num supermercado gigante, mas manter apenas um empacotador lá no final.

2:36Exato. A fila não some. A fila só muda de lugar, né? A gente acelera absurdamente a escrita. Mas e a revisão disso? Se não tem capacidade de revisão, a gente só forma um estoque caríssimo de mudança parada. O código não chega no cliente final de jeito nenhum.

2:53É perfeito. A fila foi toda para a etapa de revisão. O texto cita um conceito superinteressante chamado vibe coding, que foi cunhado por Andrej Karpathy em fevereiro de 2025. O modelo escreve o código e o humano atua quase como um diretor sabe, dirigindo o resultado por intenção e por revisão.

3:13vibe coding. Adorei o nome, mas a mecânica é pesada, porque ler o código que uma IA fez costuma ser muito mais difícil do que escrever do zero. Muito mais. Escrever uma função gigante virou tarefa de segundos.

3:26O que custa caro agora é o tempo de um profissional sênior decidir se aquela função deveria mesmo existir e revisar linha por linha. Certo. E para quem aprova o orçamento e está escutando a gente agora, qual é a solução prática?

3:40O que tem que estar no painel da próxima reunião? A diretriz da fonte é clara. O painel não deve mostrar esforço, deve mostrar entrega. Tem que pedir duas colunas específicas na próxima reunião.

3:52A primeira é, quantas entregas precisaram ser desfeitas ou reescritas? A taxa de retrabalho, no caso. Isso. E a segunda coluna é quanto tempo cada mudança levou na prática, desde o início do trabalho até chegar na mão do cliente.

4:07A verdadeira métrica de produtividade atual é a proporção entre esses dois números. Faz todo o sentido. Se a gente assume que o novo gargalo é a revisão, a gente precisa saber como diminuir o retrabalho.

4:20Como fazer as coisas passarem mais rápido e limpas por essa etapa, né? Exatamente. E é aí que entra a questão de como pedir as coisas para IA. O autor apresenta a heurística P(T).

4:31É uma regra prática com três pilares para lembrar os cuidados na hora de pedir algo. clareza, contexto e verificação. Clareza, contexto e verificação. Isso. Clareza é ter o resultado e o critério de aceite bem definidos.

4:47Contexto é passar os arquivos, as restrições e as decisões do passado. E verificação é o teste ou a demonstração de que a entrega funcionou. E onde é que os times costumam errar mais aí? Porque eu imagino que a galera tenta melhorar a clareza o tempo todo.

5:02Nossa, esse é o erro mais caro. O time recebe um código ruim da IA e tenta reescrever o pedido umas 5 vezes, brigando para melhorar a clareza. Mas, na verdade, quase sempre falta o contexto. E um modelo sem contexto responde com a média do mercado.

5:18E a média do mercado da internet não conhece as regras específicas daquela empresa, né? Nem um pouco. Por isso, a fonte traz uma regra de ouro para o executivo agir que substitui qualquer política complexa de IA.

5:30Nenhum pedido a um assistente deve começar sem declarar 5 coisas. Quais são? Repositório, a branch, que para quem não é da área, basicamente, uma linha paralela de trabalho no código, o ambiente, o problema de negócio e o critério de aceite.

5:46Tem que declarar esses cinco. Mas, vem cá, não seria mais fácil simplesmente pedir para IA, sei lá, raciocinar e planejar os passos sozinha? Já tem modelos focados em raciocínio, não tem? Tem, até tem, mas a ressalva da fonte é puramente financeira.

6:01modelos de raciocínio consumem muito mais processamento, eles elevam o custo por token absurdamente. Usar isso para tarefas puramente mecânicas é um desperdício enorme de dinheiro. Entendi. Tem que calibrar o tipo de modelo para o tamanho do problema.

6:17Agora, voltando naqueles cinco itens, você mencionou ambiente. E isso me lembra de um ponto crucial, já que a gente está falando do momento de pedir o código, é preciso entender fisicamente onde esse software vai morar, Porque o risco aumenta muito dependendo do ambiente, não é?

6:33Aumenta a cada degrau, com certeza. E a gente tem basicamente quatro degraus nessa escada. Tem o computador local de quem desenvolve, o ambiente compartilhado, o ambiente de staging ou ensaio, que é um ambiente de teste, mas com cara de produção, e finalmente a produção em si, onde o cliente real está acessando.

6:51A produção é território sagrado. E pelo que eu li na fonte, qualquer contrato com o fornecedor precisa definir uma regra inegociável sobre a produção. Qual regra, especificamente? Que a produção precisa ser um ambiente de leitura para os humanos e de escrita apenas para processos automatizados.

7:10É inaceitável, sob qualquer desculpa, permitir que o ambiente de desenvolvimento de um programador se conecte direto ao banco de dados da produção. É o famoso conserto rápido que destrói a segurança da empresa. E isso bate direto no trato dos segredos.

7:25A fonte faz uma distinção importante entre variável de ambiente e segredo. Dá um exemplo para a gente entender a diferença. Claro. Variável de ambiente é um valor que muda de degrau para degrau, tipo um endereço de servidor.

7:38Agora, um segredo é uma informação que concede acesso, tipo uma senha ou uma chave de banco de dados. E a regra é clara. Segredos nunca, jamais podem ir para o repositório de código ou para o chat de uma IA.

7:51Nossa, colocar senha em chat de IA é pedir para ter vazamento de dados. É um desastre anunciado. Por isso o curso dá uma dica de auditoria bem prática para os líderes. Pedir hoje a lista de quem tem acesso de escrita em produção e verificar quantos nomes de pessoas que já saíram do projeto continuam ativos lá.

8:13Eu te garanto, a liderança costuma ficar chocada com o resultado. Imagino mesmo. Bom, tendo protegido a produção, o líder agora tem um outro desafio gigante, que é a proposta técnica do fornecedor, sem ser engolido por aquela sopa de letrinhas maldita que eles usam para justificar orçamentos inflados.

8:33Ah, a sopa de letrinhas é um clássico de vendas, né? É, o cara vem falar de stack, arquitetura, monorepo, monólito, vende como se fosse a salvação da lavoura. Ajuda a gente a separar esses termos de forma simples? Claro!

8:48Stack é simplesmente a lista de tecnologias usadas. linguagens de programação, bancos de dados, essas coisas. A arquitetura é o desenho de quem chama quem no sistema, as fronteiras. monorepo é um repositório único guardando vários projetos diferentes.

9:06E monólito é aquela peça de software que, independente de onde o código está guardado, precisa subir para a produção como um bloco inteiro e único. Aqui é que a coisa fica realmente interessante. E é onde o orçamento pode sangrar sem o líder perceber.

9:22Ter uma stack moderna não significa nem de longe ter uma boa arquitetura. Exatamente. Pode ser só um código ruim escrito numa linguagem nova. E tem mais. Separar um monorepo em vários pedacinhos menores não significa que o sistema deixou de ser um monólito.

9:39Se o fornecedor cobra uma fortuna pela reorganização do repositório, mas na hora de publicar na produção tudo tem que subir junto do mesmo jeito, O cliente está pagando por uma mudança que já existia na prática. É um ganho cosmético que não muda a agilidade.

9:55E aí a fonte revela a palavra mágica para aprovar orçamentos.

10:01Reversibilidade. Reversibilidade. Isso que é basicamente quanto custa desfazer uma escolha técnica. Decisões caras e difíceis de reverter exigem comitê e muita deliberação. Decisões baratas podem ser testadas e é daí que surge a temida dívida técnica, que é aquele atalho tomado hoje que cobra juros altos em cada mudança futura que o time tentar fazer.

10:25Então, qual é a missão do executivo quando recebe essa proposta cheia de termos técnicos? A missão não é desenhar arquitetura, mas é perguntar ao fornecedor na lata. Qual é o custo e o prazo para desfazer os três itens mais caros dessa proposta?

10:41Se a pessoa não souber responder, não assina o cheque. Excelente. É um teste de fogo para a proposta. Mas digamos que passe. Aí o fornecedor muda de slide e, inevitavelmente, mostra um número mágico.

10:54O slide prometendo ganhos imensos de produtividade com a adoção da IA. 80% mais rápido, dobro de entrega, essas coisas. Como a gente lê esses números sem ser enganado? O Alexandre Caramaschi categoriza esses números em três níveis de evidência.

11:09E a gente precisa olhar bem para eles. O nível 1 é o que a gente chama de telemetria, que são os registros automáticos. E a fonte cita um ensaio de julho de 2025 com 16 desenvolvedores. E o que aconteceu nesse ensaio?

11:24A telemetria mediu 19% mais lentidão com o uso da IA. Eles ficaram mais lentos. Mas o fascinante foi que eles estimavam, na percepção deles, estar entre 20% a 24% mais rápidos. Nossa, a percepção humana foi totalmente descolada da realidade dos registros.

11:44Eles sentiam que estavam voando, mas, na verdade, estavam atrasando o processo. Pois é. E aí, em fevereiro de 2026, a amostra desse ensaio foi ampliada. Mas o resultado ficou totalmente inconclusivo, variando de menos 38% até mais 9% de produtividade.

12:04Inconclusivo por quê? A ferramenta era instável? Não, o comportamento humano mesmo, a fonte diz que de 30 a 50% dos desenvolvedores se recusaram a trabalhar sem IA. Isso enviesou o estudo completamente.

12:18Mas no nível 1 ainda, o autor cita o estudo observacional da Faros. Ah, esse estudo da Faros é bem emblemático, né? Muito. Foram 2 anos, 22 mil pessoas desenvolvedoras e 4 mil times. eles encontraram um aumento de 242,7% nos incidentes.

12:38242% de aumento em incidente. É assustador. E tem mais. Eles mediram um aumento de 441,5% na mediana do tempo de revisão. Olha o gargalo aí se confirmando. A revisão travou tudo. Mas a gente precisa ser justo aqui também.

12:58A própria fonte faz questão de avisar que esse estudo da Faros é observacional. A associação não é causalidade. E também reforça que não é uma pesquisa oficial do DORA, que é o padrão ouro do mercado. Exato. O texto deixa isso bem claro.

13:13Não dá pra cravar como lei absoluta, mas é um indício fortíssimo. Aí a gente vai para o nível 2, que são as declarações de fornecedores. Em maio de 2026, a Anthropic relatou que mais de 80% do código escrito lá dentro era por modelo.

13:3080%, um número lindo para o slide de vendas. Lindo? Mas eles colocaram uma ressalva explícita de que isso superestimava o ganho real de produtividade. O problema é que, como você disse, quando vai para o slide de vendas, essa ressalva sempre some, desaparece por mágica.

13:49Claro, o slide não aceita nuances. E o nível 3, qual é? O nível 3 é sem fonte nenhuma. São números soltos e matemática criativa. A fonte dá o exemplo de tentar subtrair aqueles 42% de código de origem de IA de uns 27,4% de código integrado no primeiro trimestre de 2026, que já tinha subido contra os 22% do trimestre anterior.

14:17É uma salada de números que não conversam entre si. Totalmente. O autor avisa explicitamente. Metodologias diferentes não formam funil. Não dá para cruzar dado de uma pesquisa com a outra e achar que achou a verdade. E o antídoto para isso?

14:34Qual é a defesa do executivo na sala de reunião? O antídoto vem do alerta do DORA de junho de 2026. A regra de ouro é consumir tokens não comprova produtividade. Tem que aplicar quatro perguntas a qualquer número do slide.

14:49Quem mediu, quando, com que a amostra e o que essa pessoa ou empresa vende. Perguntas implacáveis. Quem mediu, quando, a amostra e o que estão vendendo. Isso já derruba muita promessa furada. Mas sabe, ouvindo tudo isso, me vem uma conclusão.

15:07Se a métrica final não garante o ganho e o fornecedor pode brincar com os números, O verdadeiro controle do executivo não está na linha de chegada. Não está mesmo? Está na linha de partida do projeto, participar do planejamento para poder revisar menos no fim.

15:23É exatamente esse o pulo do gato, e a mudança de chave no planejamento é a diferença entre pedir funcionalidade e pedir capacidade desejada. E qual é a diferença prática entre as duas? Pedir funcionalidade é pedir uma lista de telas, botões, relatórios.

15:38Isso gera retrabalho, porque quem está desenvolvendo fica tentando adivinhar o impacto para o negócio. Agora, nomear uma capacidade desejada é focar no resultado observável pela empresa.

15:48E tem aquele caso na fonte, o cenário ilustrativo da distribuidora Aurora. É bem didático. Quando a liderança chegou e pediu, tipo, um painel de estoque, que é uma funcionalidade, eles sofreram três rodadas inteiras de ajustes, perdendo um tempo enorme.

16:04É, três idas e vindas dolorosas. Mas aí a liderança mudou a abordagem. Em vez de pedir o painel, eles pediram a capacidade desejada que era, saber em que dia cada centro de distribuição fica sem produto.

16:17E eles combinaram de antemão qual era a evidência de sucesso. E o resultado disso? A entrega fechou em apenas uma rodada. Uma rodada de revisão e estava pronto. Sensacional! Porque a orientação prévia foi clara. Exato.

16:31A fonte reforça que o planejamento perfeito exige contexto prévio. O que isso significa? Tem que ter limite de tempo e de orçamento. Tem que deixar claro que é inegociável, tipo regras de segurança.

16:43Tem que dizer o que o time de tecnologia decide sozinho, a autonomia deles, e qual evidência, qual teste ou demonstração final fecha a entrega e dá como concluído. Entregas pequenas, com expectativas claras, mantêm a revisão humana super rápida e baseada na evidência que já estava combinada antes de escrever qualquer código.

17:04A falta dessa clareza empurra o custo inteirinho para a fase de revisão, que é onde a gente vê aquele aumento de 441% no tempo de revisão que o estudo da Faros notou. É a conta chegando no final da esteira. Se não planeja bem, a revisão paga o pato.

17:20Isso nos traz de volta para a imagem da nossa abertura. O nosso executivo ou a nossa executiva com o orçamento de IA na mão suando frio. A decisão correta, então, não é tentar desenhar a ferramenta ou entrar na minúcia técnica de como a IA vai ser implementada.

17:36Longe disso, a decisão correta da liderança é exigir a linha de base da empresa primeiro. Como estava a entrega e o retrabalho nas quatro semanas anteriores a essa ferramenta. Depois, estipular o prazo do piloto.

17:50E mais importante, nomear a capacidade desejada logo na reunião de planejamento, não pedir só o botão. E claro, testar de forma rigorosa a fonte primária de cada número mágico que vier na proposta do fornecedor. É um roteiro de sobrevivência completo.

18:05Para fechar esse mergulho de hoje, acho que a gente tem espaço para uma reflexão final que puxa um pouco o horizonte para frente, não tem? Temos. E é uma reflexão bem provocativa baseada na própria premissa do autor. Pensa comigo.

18:18Se a gente assume que a digitação não é mais um gargalo e que a habilidade mecânica de escrever código está caminhando rápido para um custo próximo de zero. Certo. Será que no futuro bem próximo, as empresas de tecnologia não vão mais ser avaliadas pelo código ou pelo software que elas têm estocado, a grande vantagem competitiva talvez passe a ser a precisão com que os líderes daquela empresa conseguem articular o contexto e os problemas de negócios para que as máquinas resolvam.

18:46Olha, se o código vira commodity, quem souber fazer a pergunta certa para máquina é quem vai dominar o mercado. Fica essa reflexão pesada para quem acompanha a gente hoje. É isso aí. Fica o pensamento.

18:59Valeu demais pelo mergulho de hoje e pelas análises. Até a próxima!