Eu fui convidado para falar sobre IA e o “dev do futuro” em um encontro de tecnologia do time da Petlove. As perguntas que me passaram no roteiro foram sensacionais e eu decidi publicá-las junto com as minhas respostas.
1. Qual o maior mito ou exagero sobre IA na construção de software hoje que você gostaria de derrubar logo de cara?
São dois. E vou começar polêmico aqui, pra tirar vocês da zona de conforto.
Primeiro, que IA escreve código feio. Isso talvez tenha sido verdade lá atrás, no começo. Mas há muito tempo, isso não é real. Mesmo antes do Opus, o Haiku era muito bom em seguir instrução e “aprender de exemplos”. A IA hoje escreve código da forma exata com que você pede, com que ela encontra no contexto, com que ela aprende de exemplos. Se escreveu código “feio”, basta ensinar ela pra não fazer mais isso.
Segundo, que pessoas de produto, produteiros, vão codar. Se LLMs aceleram a escrita de código, pq precisamos de mais gente escrevendo código? O gargalo agora é outro, é entender o que construir.
E agora que construímos mais rápido, precisamos priorizar ainda melhor, senão vamos gastar nosso “novo ganho de produtividade” produzindo coisa que ninguém quer.
Acredito muito no conceito de “Citizen developer” do Gartner, onde apps simples do dia-a-dia, agentes, etc, serão codadas por não-techies, mas a sua aplicação master-ultra-complicada ainda será liderada por engenheiros.
2. O que de fato mudou na engenharia com LLMs (code review, pair, documentação) e o que tentaram forçar e não pegou? Dá pra cravar um ganho de produtividade real, algo como 10, 30 ou 50%? Muda entre júnior e sênior?
Escrever código virou commodity. Mas isso não quer dizer que ficou mais fácil entregar software. Na verdade, ao contrário, ficou mais difícil. Escrever código sempre foi a parte “fácil”, só que até então levava tempo. Garantir qualidade, agora em escala, é a parte difícil; saber o que fazer primeiro, priorização, é a parte difícil.
Outra coisa que mudou é que as LLMs consolidaram algo que já falávamos há muito tempo: “o dev não é pago pra escrever código, ele é pago pra resolver problema”.
As lideranças de engenharia já pensavam assim, mas antes, o dev que era pago só pra escrever código ainda tinha espaço. Hoje em dia, não tem mais. Quem ganhou espaço foi aquele dev que resolve problema.
Sobre o que não pegou, eu ainda não estou 100% comprado com a ideia de SDD (spec-driven development). Não acredito ainda em um universo onde você não precisa conhecer nada do seu código. Mas quem sabe mais pra frente.
3. Como manter o senso crítico do time?
É uma mudança grande na forma de trabalho e nesse tipo de situação, é sempre muito sobre como a liderança passa a mensagem para o time.
Com meu time, fui sempre muito claro sobre o fato de que precisamos usar IA para escrever código. Não há volta. Mas também não quero abrir mão de qualidade. E que conto com a ajuda deles para irmos aprendendo como maximizar nossa produtividade com IA.
Eles foram aos poucos criando skills específicas, acertando os arquivos de contexto, etc. Ao contrário de outros líderes, onde a mensagem foi mais do tipo “não quero saber, usem IA agora, tá todo mundo usando, vai vai vai”.
4. Tirando treinamento e ferramenta, quais são as 2 ou 3 alavancas que mais moveram adoção real de IA no dia a dia e o que você tentou que não funcionou? Como fazer a IA virar o default no fluxo e não um app opcional?
Cara, aqui pra mim foi muito sobre a influência da liderança. No começo, tentamos seer bem bottom-up. “Vai lá, usa, experimenta”. Não deu certo. Adoção aqui e ali, nada sistêmico. Aí, eu vim com uma mensagem mais forte, “IA é parte do dia a dia”, preparamos um evento legal sobre isso, definimos regras como revisão de código, uso de IA e governança básica.
Identificamos champions dentro do time e esses próprios champions começaram a fazer barulho e nos ajudar. Enfim, precisou ser uma mistura de top-down e bottom-up. E aí começou a fluir melhor.
5. Capacitação em escala: o modelo de champions ou âncoras funciona, e em que proporção (1 pra quantos)? Certificação (Anthropic e afins) gera resultado prático ou é mais marketing? E como capacitar gente não técnica a construir com segurança?
Certificação, não sei dizer, nunca fui fã, nem vendemos isso hoje na Alura.
Sobre treinamento, sou enviesado, claro, é meu ganha-pão, mas o que vemos não só no mercado mas dentro de casa, é a diferença brutal de entrega entre um “dev que sabe o que faz” vs “um dev que não sabe”. Sempre foi assim na real, com qualquer nova tecnologia, ferramenta, etc, IA é mais uma.
A diferença é que agora a diferença entre o dev que sabe e o que não sabe não é 2x, é 10x.
6. Story points e velocity ainda fazem sentido na era da IA, ou o que você usaria pra previsibilidade? E como separar ganho real de produtividade de uma aceleração artificial que esconde dívida ou queda de qualidade? Quais são os sinais de alerta?
Acho que nunca fez, hehehe. Eu posso passar uma hora aqui com vcs reclamando dos métodos ágeis e como algumas das ideias dessa galera de 25 anos atrás não envelheceu bem e a gente ainda tenta aplicar como se fosse bala de prata, mas acho que fica pra próxima.
Medir produtividade sempre foi difícil. Você consegue realmente medir produtividade do seu time hoje? O máximo que fazemos é apelar para algumas métricas proxies e acompanhá-las ao longo do tempo, conforme você vai implementando novos processos.
Eu optei por medir throughput de código e incidentes. Throughput de código porque, afinal, estamos falando que escrever código é commodity. Logo, eu espero mais código sendo escrito. E incidentes, porque não quero que minha aplicação pare de funcionar porque eu pedi para todo mundo usar IA.
Por enquanto, está ótimo, 2.5 a 3x mais código e zero incidentes.
Ah, mas vocês estão entregando mais? Claro que estamos, código em produção é entrega. Estão entregando mais coisa de valor? Não sei, mas isso não tem nada a ver com IA, tem a ver com como priorizamos produto.
7. Vocês continuam colocando tarefa no Jira ou o workflow está migrando pro agente? E as cerimônias ágeis (daily, planning, retro) ainda fazem sentido quando parte da entrega é feita por agente autônomo e o ciclo encurta? O que vocês mudaram?
Não mudamos nada nos rituais dos times. Os times são autônomos para definir a maneira de trabalhar.
Mas ainda não estamos no estágio onde o dev só abre o ticket no Jira e um agente já pega o ticket a partir dali.
Temos experimentado com a ideia de Minions, agentes autônomos de código que resolvem tarefas mais pontuais. Agora, funcionalidade grande mesmo, por enquanto, o humano que dirige.
8. Pra um líder puxando adoção de IA numa organização de 1400+ pessoas: o que você faria nos primeiros 90 dias e o que evitaria?
Estamos com o mesmo desafio (1.5k colaboradores) e vou adorar acompanhar e aprender junto com vocês, porque temos as mesmas dores.
Como falei, eu comecei pelo meu time de tech, em uma combinação top-down e bottom-up. Estou bem feliz com a adoção e estamos melhorando cada dia mais.
Nosso próximo passo é com outras áreas. Tá todo mundo experimentando aqui e ali, mas resolver realmente um problema end-to-end se você não é de tech, é mais difícil. Já temos aqui e ali aplicações vibe codadas por pessoas, acho que umas 30, e um bom número delas bem legais.
Mesmo sendo tech-savvy, poucos realmente conseguem elevar pro próximo nível. Estamos organizando um time de FDEs interno para atuar junto com as áreas.
9. Daqui 5 anos, como você imagina a construção de produtos digitais? Quem escreve o código, o que sobra pro dev, pro PM e pro designer, o que desaparece e o que aparece de novo?
Pessoal, até como posicionamento pessoal, eu decidi não fazer parte do time de futurólogos da internet que ficam predizendo o futuro. “Ah, o dev morreu, ninguém mais vai escrever código”, “Ah, fica tranquilo, que o custo da IA vai cair pra zero, vai ser igual a internet”.
Tudo isso pode até virar verdade, mas eu sou pé no chão, tenho resultado pra entregar, então gosto de olhar para o que tenho hoje e usar o que tenho pra melhorar o trabalho da minha equipe e da minha empresa.
O futuro eu deixo pro polvo que vê o campeão da copa e pra moça que disse que o Neymar seria abduzido no minuto 38 do jogo contra a Escócia.
10. O que vocês medem para saber se a IA está gerando valor de verdade? Quais métricas funcionaram e quais se mostraram vaidade? Como provar ROI para liderança e CFO?
Para medir o impacto de IA, estou usando as métricas que comentei acima, throughput de código e incidentes em produção.
Não precisei ficar discutindo número com o CFO, até porque fui bem contido nos gastos com IA.
11. Agentes estão entregando o que prometem ou ainda existe muito hype? O que hoje já funciona de forma confiável em produção e o que ainda parece mais demo do que realidade?
Você tem que definir sua expectativa. A minha é de que IA acelera escrita do código. Não mais do que isso por enquanto. Eu adicionei a minha trava: qualidade. Quero o menor número possível de incidentes. E, por enquanto, estou feliz com o resultado.
12. Onde a IA mais decepcionou até agora? O que parecia inevitável há 1 ano e não aconteceu? E o que continua dependendo muito mais de humanos do que o mercado imaginava?
De novo, questão de expectativa. Algumas pessoas colocaram a expectativa lá no alto. IA vai mudar o mundo, agentes vão fazer tudo. A realidade é que IA ainda só está maximizando produtividade local, não sistêmica. Poucos são os casos de uso de verdade onde o fluxo completo foi automatizado por IA.
A IA não gerou “nada de novo”, apenas automatizou fluxos que já existiam. Aliás, por isso que não gosto da comparação com a revolução industrial, eletricidade.
A eletricidade nos permitiu fazer coisas impossíveis antes, a IA está basicamente automatizando fluxos que já fazíamos. “Ah, mas o iFood aumentou conversão de sei-lá-o-quê em tantos por cento”, fluxo que já existia e que agora dá pra fazer com um robô por um preço mais barato.
13. O que você procura hoje em um engenheiro, PM ou designer que não procurava há 2 anos? Quais habilidades ficaram mais valiosas e quais perderam relevância?
“Bom gosto”. Fazer produto ficou fácil. A diferença do meu produto e do seu produto é o meu “bom gosto” em pensar na experiência do usuário. Antes você conseguia escalar isso com uma equipe de UX, que conseguia dar vazão para o número limitado de experiências realmente inovadoras que você lançava por mês.
Agora, esse número de experiências cresceu. Você vai precisar escalar “bom gosto”, todo mundo precisa ter, porque o dev ou o produteiro ou sei lá quem vai precisar conseguir tomar decisão de experiência, de UX, de maneira independente. A IA não consegue.
14. Se você estivesse começando do zero hoje, que conhecimentos e ferramentas priorizaria para se manter relevante nos próximos anos?
Como dev, eu não abriria mão ainda de entender dos fundamentos. Não acredito ainda que código vai desaparecer e nunca mais vamos precisar ler código, entender do framework, entender de arquitetura e de banco de dados.
Como produteiro, priorização e “bom gosto”. Não acho que produteiros vão codar, de novo, essa é a parte fácil, priorizar é o gargalo.
