Ep. 294 - O que a IA está mudando no desenvolvimento de software

Neste episódio, Rafa conversa com Danilo e Felipe (que também se apresenta como Peter Nella), sócios da K21/Nower e fundadores da WBrain, sobre o que a inteligência artificial está mudando no desenvolvimento de software, tanto na programação em si quanto na gestão e organização das equipes.

A conversa começa definindo o que de fato é IA hoje: na prática, o que o mercado chama de AI são LLMs, modelos de machine learning treinados com um volume gigantesco de dados para entender e gerar linguagem natural. Não existe ainda uma inteligência artificial no sentido de cognição real; é um grande modelo probabilístico que gera, a partir de estatísticas sobre conexões de dados, um resultado que estatisticamente faz sentido, e é por isso que ocorrem alucinações e informações inventadas. O ChatGPT não inventou essa tecnologia, mas foi o que a popularizou e levou ao grande público.

Para explicar isso a clientes, Danilo e Peter Nella usam o conceito de três camadas: a camada mais básica são os LLMs (os motores, como Opus, Sonnet ou GPT); a segunda camada são as APIs que dão acesso direto a esses motores, para as quais se envia um prompt, sendo importante entender que o LLM não tem memória própria; e a terceira camada são os softwares que envolvem esse prompt com outras informações antes de mandá-lo para a API, como Lovable, Gama, n8n ou os próprios chats. Mesmo quem não é desenvolvedor, ao usar qualquer uma dessas ferramentas, está acessando toda essa cadeia, e é isso que gera custo de tokens e gasto energético.

Sobre como isso muda a forma como as equipes se organizam, os convidados dividem o uso da IA em dois modos: como assistente, quando ela potencializa tarefas pontuais de uma pessoa (reescrever um e-mail, resumir um texto, completar um código), uso que cabe bem nas assinaturas mensais; e como coautora, quando o desenvolvedor humano passa a atuar como gestor e arquiteto de um 'desenvolvedor IA', validando, verificando e planejando junto com ele. Nesse segundo modo, as medições internas da equipe apontam que um desenvolvedor consegue produzir de quatro a seis vezes mais código no mesmo tempo, sem necessariamente perder qualidade, desde que já fosse um profissional disciplinado antes.

Esse ganho de vazão está reduzindo o tamanho dos times de desenvolvimento: onde antes eram necessários três, quatro ou mais desenvolvedores, hoje muitas vezes bastam um ou dois, formando micro-times que viraram o novo padrão. A verificação manual de qualidade também já vinha perdendo espaço, com a IA sendo orientada a escrever primeiro os testes (TDD) antes do código, uma disciplina que antes dependia de o programador ser muito rigoroso.

Mas esse cenário ideal, de um software nascendo do zero sem legado, esbarra em um problema real: a capacidade de produzir passou a ser maior do que a capacidade de testar e validar se aquilo é realmente necessário. Um cliente que sentia dor com erros em um relatório manual pediu a automação; em 15 dias o sistema estava pronto, mais rápido do que o próprio cliente conseguiu organizar a medição do problema original, e quando finalmente mediu, descobriu que o erro real era de apenas 1 em 400 casos, o que talvez nem justificasse ter automatizado. A conclusão é que hoje é mais rápido desenvolver do que avaliar se aquilo vale a pena, o que deve gerar mais 'lixo digital', mas também habilita pessoas com pouco conhecimento técnico a experimentar e materializar ideias que antes eram inviáveis.

Esse cenário desloca o gargalo: antes ele estava na fila de desenvolvimento, hoje ele está migrando para a validação e para a especificação do que realmente vale a pena construir, e para o aging das demandas, que passam menos tempo esperando no backlog. Ao mesmo tempo, cresce o shadow IT, pessoas de áreas de negócio resolvendo seus próprios problemas com IA sem passar pela área de tecnologia, algo que já era comum antes com automações em Excel e que agora se intensifica. PMs e POs também passam a usar IA para prototipar interfaces e fluxos, o que já funciona como uma forma de documentação viva do que precisa ser desenvolvido.

Para dar conta disso com segurança, a recomendação é que as empresas montem um time de habilitação técnica, com um arquiteto e um gestor, responsável por criar ambientes seguros: servidores MCP, guardrails, toolkits e instruções para os LLMs, conectando tudo às APIs através de protocolos próprios da empresa, em vez de deixar times soltos usando sistemas abertos e compartilhando dados sem controle, o que também abre brecha para ataques que manipulam o resultado que o LLM devolve.

Por fim, os convidados reforçam que esse movimento não é sobre redução de desenvolvedores, e sim sobre aumento de vazão: como o mercado é competitivo, mais capacidade produtiva não reduz demanda, ela é absorvida, exigindo inclusive mais gente de negócio para acompanhar o ritmo dos times técnicos, um padrão que se repete historicamente com toda nova tecnologia adotada pela humanidade, o chamado paradoxo de Jevons. Como conselho final, Peter Nella recomenda experimentar e ganhar conhecimento como única forma de se apropriar da tecnologia, e Danilo reforça que, como qualquer ferramenta que aumenta capacidade produtiva, ela dificilmente será rejeitada e precisa ser dominada para manter a competitividade.