Como usar IA para multiplicar expertise (não substituir aprendizado)
Como veteranos multiplicam produtividade sem comprometer qualidade
Semana passada, Codecon Select, conheci o Zarathon Viana, Head of Engineering do Quinto Andar. Ficamos quase meia hora discutindo IA e desenvolvimento de software. O entusiasmo dele era contagiante.
O Zara me contou algo fascinante: depois de quase 10 anos focado em system design, arquitetura e gestão de pessoas (mal colocando a mão no código), ele voltou a programar. E a razão? LLMs.
Isso me chamou atenção porque não é um caso isolado.
Armin Ronacher, criador do Flask, passou de cético a entusiasta de LLMs em 6 meses. Kent Beck, criador do Extreme Programming, diz que está se divertindo mais programando do que em 52 anos de carreira. Peter Steinberger, fundador da PSPDFKit, voltou a codar diariamente depois de anos afastado.
Mais casos como esse você confere no artigo do Gergely do Pragmatic Engineer.
Algo mudou. E mudou rápido.
Mas aqui está o que poucos percebem: enquanto 88% das empresas já usam IA, apenas 33% conseguiram escalar essas tecnologias de verdade. Os outros 67%? Estão experimentando, testando, tentando descobrir como extrair valor real.
A fonte deste dados, e o minha análise, você vai ver daqui a pouco. Continue lendo!
Por que essa diferença brutal?
Porque LLMs não eliminam a necessidade de aprender profundamente. Elas multiplicam o valor de ter fundamentação sólida.
É como ter um assistente extremamente capaz. Se você não sabe o que pedir, ou não consegue avaliar o que recebe de volta, o assistente não ajuda. Pior: pode te atrapalhar.
Mas se você domina os fundamentos? Arquitetura, trade-offs, product sense. Então LLMs se tornam o acelerador mais poderoso que já existiu em engenharia de software.
Nos últimos meses, usei LLMs para construir toda a plataforma do NaGringa, chegar no top 3 do Google em várias keywords competitivas, e faturar R$ 90 mil com um side business. Tudo isso trabalhando em tempo integral em outra empresa competitiva.
Não porque sou especial. Mas porque aprendi a usar essas ferramentas em máxima eficiência. E o que descobri nesse processo pode mudar completamente como você pensa sobre sua carreira nos próximos anos.
✨ O que esperar do artigo
Como veteranos céticos se tornaram os maiores defensores de LLMs (e o que isso revela sobre quem realmente se beneficia dessas ferramentas)
O fluxo real de trabalho com agentes paralelos que me permitiu 10x meu output sem comprometer qualidade, incluindo os trade-offs honestos que ninguém fala
Por que fundamentação técnica importa MAIS agora, não menos. E como diferenciar desenvolvedores que vão dominar essa nova era dos que vão ficar para trás
Por que veteranos com décadas de carreira mudaram de ideia
Um dado impressionante: 88% das empresas já usam IA regularmente. Mas aqui está o detalhe que importa: apenas 33% começaram a escalar essas tecnologias de verdade.
Os outros 67%? Estão experimentando. Testando. Ainda tentando descobrir como extrair valor real dessas ferramentas.
E sabe quem está no grupo dos 33% que realmente faz acontecer? Engenheiros com anos (às vezes décadas) de experiência. Ou, com uma curiosidade genuína pela capacidade destes sistemas.
Não é coincidência.
A virada dos céticos
Armin Ronacher foi enfático por meses: ferramentas de IA para desenvolvimento não valiam a pena. Até que, há alguns meses, algo mudou. Ele publicou um artigo chamado AI changes everything:
“Se você tivesse me dito há 6 meses que eu preferiria liderar um engenheiro virtual a simplesmente programar eu mesmo, eu não acreditaria. Agora, posso ir fazer um café e o progresso continua acontecendo. Posso estar no parquinho com meu filho enquanto o trabalho avança em segundo plano.”
Peter Steinberger, que construiu e vendeu uma empresa de US$ 100 milhões, estava afastado do código diário. Agora? Está programando todos os dias de novo. Ele descreveu como “o momento mais empolgante desde que aprendi a programar”.
Kent Beck, com 52 anos de carreira, resume: “Estou me divertindo mais programando do que nunca.”
O que mudou?
Não foi um salto súbito de capacidade dos modelos. Foi a combinação de três fatores:
Ferramentas maduras: Claude Code, Cursor, e outros agentes chegaram num ponto de confiabilidade onde você pode delegar tarefas não-triviais
Aprendizado sobre como usar: descobrimos que não é sobre substituir programação, mas sobre arquitetar soluções e dirigir execução
Infraestrutura pronta: ferramentas como MCP (Model Context Protocol) tornaram integração trivial
Mas aqui está o ponto crucial: todos esses engenheiros que mudaram de ideia têm algo em comum.
Eles têm 10+ anos construindo sistemas complexos.
Eles não aprenderam a usar LLMs porque assistiram um tutorial. Eles já sabiam exatamente o que precisava acontecer: o contexto necessário, os edge cases, os trade-offs. As LLMs apenas aceleraram a execução.
É como a diferença entre dar direções para alguém que conhece a cidade versus alguém que nunca esteve lá. Se você não sabe para onde está indo, o GPS mais avançado do mundo não ajuda.
O que os dados mostram
O relatório mais recente da McKinsey sobre IA empresarial confirma: apenas 6% das empresas são “high performers” com IA. São aquelas que realmente capturam valor significativo.
Por uma feliz coincidência, esse relatório saiu logo na semana onde eu quis escrever um artigo detalhado sobre isso tudo. 🙏
E o que diferencia esse 6%?
Eles redesenham workflows 3 vezes mais do que o resto. Não estão apenas usando a ferramenta. Estão repensando fundamentalmente como trabalham.
Isso não acontece por acidente. Requer entender profundamente:
Onde está o gargalo real
Que partes do processo podem ser aceleradas
Que partes precisam de mais atenção humana
Como validar que o resultado está correto
Tudo isso vem de experiência. De ter passado por centenas de situações diferentes. De ter construído features que funcionaram e features que falharam.
LLMs amplificam seu julgamento. Se seu julgamento é fraco, a amplificação não ajuda.
Esse é um assunto que já escrevi antes. Salve para ler depois:
Como máxima eficiência funciona na prática
Deixa eu ser direto sobre meu fluxo atual, porque é aqui que a teoria encontra a realidade.
Não estou sozinho quando trabalho. Uso múltiplos agentes em paralelo:
Durante o standup diário, um agente já está investigando uma issue não-crítica em produção. Analisando logs, identificando a query problemática, propondo solução.
Enquanto foco na feature principal, outro agente está na minha pasta da newsletter revisando o outline do próximo artigo. Sugerindo histórias reais que posso incluir baseado nos artigos anteriores.
Quando preciso de um plano de implementação, uso o Claude Code em modo “plan”. Ele desenha a arquitetura da solução, identifica as partes que precisam de atenção, sugere a ordem de implementação. Reviso o plano, ajusto, e então deixo ele implementar enquanto foco em code reviews.
Esse é o fluxo.
Não é mágica. Não é “IA faz tudo”. É orquestração. É usar múltiplos agentes em paralelo, cada um em uma tarefa específica, enquanto você atua como o gerente de projeto e arquiteto desse time virtual.
Os resultados concretos
Desde que dominei esse fluxo:
No trabalho: Minhas PRs aumentaram em velocidade e qualidade. Consigo pegar features mais ambiciosas porque sei que posso iterar rápido. Meu time me vê como alguém que desbloqueia problemas, não apenas entrega código.
No NaGringa: Construí a plataforma completa sozinho. Sistema de checkout com Stripe, Asaas e Abacatepay. Controle de acesso a conteúdo premium. Portal de vagas customizado. Tudo isso em paralelo ao trabalho full-time.
No marketing: Criei ferramentas (calculadora CLT vs PJ, gerador de invoice, calculadora juros compostos) que hoje me trazem milhares de visitantes orgânicos por mês. Estou no top 3 do Google para “calculadora clt pj”.
No faturamento: R$ 90 mil desde o lançamento do portal de vagas NaGringa, há 5 meses. Tudo isso enquanto trabalho em tempo integral.
Não estou falando disso para me gabar. Estou falando porque isso não seria possível há 2 anos. Simplesmente não daria tempo.
E aqui está o ponto: eu não sou o único. Dados da McKinsey mostram que os “high performers” (6% das empresas) que realmente capturam valor com IA fazem exatamente isso: redesenham workflows completamente.
Eles não usam IA para fazer as mesmas coisas 10% mais rápido. Eles repensam o que é possível quando código fica mais barato de produzir.
O que continua sendo caro
Mas nem tudo ficou mais fácil. Alguns gargalos continuam (ou até aumentaram):
1. Verificação
Code review continua sendo essencial. Talvez até mais importante agora. Porque é fácil gerar muito código rapidamente. Mas garantir que esse código é correto, maintainável, e não introduz bugs sutis? Isso requer atenção.
Hoje gasto mais tempo revisando do que programando do zero. E isso é OK. É onde meu valor está.
2. Saber O QUE construir
Essa é a parte cara agora. Com LLMs, fazer qualquer feature ficou barato. O risco? Encher o produto de features desnecessárias.
Product sense (entender o que realmente resolve o problema do usuário, o que pode ser ignorado, como priorizar) ficou mais importante, não menos.
É a diferença entre engenheiros que “entregam tickets” e engenheiros que “constroem produtos que encantam”.
3. Contexto e arquitetura
Para LLMs funcionarem bem, elas precisam de contexto. Muito contexto. E organizar esse contexto (ter uma arquitetura clara, documentação atualizada, testes que validam comportamento) não mudou.
Na verdade, ficou mais crítico. Porque se sua arquitetura é uma bagunça, a LLM vai produzir código que perpetua a bagunça. Garbage in, garbage out.
E aqui está algo que poucos percebem: uma cultura de excelência em engenharia de software acelera ainda mais o uso de LLMs.
Quando você tem:
Arquitetura bem definida e documentada
Testes que validam comportamento
Padrões claros de código
Processos de review estabelecidos
Não só as pessoas ficam melhores. Os agentes também. Porque o contexto está lá. A estrutura está clara. Os exemplos de boa prática estão visíveis.
Times que já tinham excelência técnica multiplicam seu impacto muito mais rápido com LLMs. Times que eram desorganizados continuam desorganizados, só que agora mais rápido.
É por isso que fundamentação importa tanto.
Nem tudo são flores
Não vou mentir: minha capacidade de trabalhar profundamente em problemas realmente desafiantes pode ter diminuído um pouco.
É mais fácil iterar com o Claude do que sentar por 2 horas pensando profundamente numa solução. E tem momentos que essa iteração rápida é o caminho certo.
Mas tem momentos que você precisa parar, desconectar, e realmente pensar no problema.
O segredo é saber quando usar cada abordagem.
Problemas bem-definidos? LLM pode acelerar muito. Problemas ambíguos que exigem criatividade ou trade-offs não-óbvios? Você precisa pensar primeiro, só então usar LLM para acelerar execução.
É como pair programming. Às vezes você dirige, às vezes você navega. Com LLMs, você está constantemente alternando entre esses papéis.
O que “fundamentação” significa agora
Se você chegou até aqui esperando que eu dissesse “não precisa mais aprender fundamentos, LLMs fazem tudo”, sinto desapontá-lo.
A verdade é exatamente o oposto.
Fundamentação técnica importa MAIS agora. Mas o que mudou é QUAL fundamentação importa, e COMO você a usa.
Você virou um Engineering Manager
Pensa assim: antes, você era um individual contributor. Você programava. Debugava. Implementava features do início ao fim.
Agora? Você gerencia um time de agentes extremamente capazes, mas que precisam de direção clara.
E o que faz um bom engineering manager?
Define o problema claramente: Não apenas “faz X”. Mas “resolvemos Y porque Z, e X é uma solução possível. Considera A, B, C no design.”
Valida o trabalho constantemente: Code review virou sua principal atividade. Você precisa identificar quando algo está errado, incompleto, ou pode introduzir bugs.
Desbloqueia quando necessário: Quando o agente trava, você precisa entender o problema e dar a direção certa. Isso requer expertise técnica profunda.
Garante qualidade: Arquitetura, testes, observabilidade. Você define os padrões que o time (de agentes) deve seguir.
Dados da McKinsey confirmam: high performers têm liderança 3x mais engajada com IA. Não é sobre “deixar a IA fazer tudo”. É sobre dirigir o uso de IA com clareza de propósito.
Você também virou um Product Manager
Além de gerenciar execução, você precisa saber O QUE construir.
E isso requer outro conjunto de habilidades:
Product sense: Qual feature resolve o problema real? Qual é nice-to-have? O que complica sem adicionar valor?
Entender trade-offs: Cada decisão tem custo. Complexidade, maintainability, performance. Você precisa avaliar esses trade-offs constantemente.
Medir impacto: Como saber se o que você construiu funcionou? Quais métricas acompanhar? Como iterar baseado em feedback?
Simplicidade intencional: Resistir à tentação de adicionar features só porque “agora é fácil”. Produtos que encantam são simples, não cheios de features.
Essas habilidades sempre foram importantes. Mas agora são críticas, porque a barreira para construir qualquer coisa caiu drasticamente.
Por que juniors têm mais dificuldade
Aqui está uma verdade difícil: juniors estão em desvantagem nesse novo mundo.
Não porque são menos inteligentes. Mas porque falta o mapa mental que vem de anos construindo sistemas.
Quando um senior vê um problema, ele imediatamente reconhece padrões:
“Já vi isso antes, é um problema de N+1 queries”
“Esse design vai causar race conditions no futuro”
“Essa solução funciona agora mas não vai escalar”
Esse reconhecimento de padrões vem de experiência. De ter feito errado várias vezes. De ter visto sistemas quebrarem em produção.
LLMs não substituem esse conhecimento. Elas amplificam ele.
Se você não reconhece os padrões, não sabe que perguntas fazer. Não sabe quando a LLM está sugerindo algo problemático. Não sabe como direcionar melhor.
É como a diferença entre alguém que aprendeu a dirigir com GPS desde o dia 1, versus alguém que aprendeu lendo mapas. Quando o GPS falha, quem tem o mapa mental navega. Quem não tem fica perdido.
Por isso, se você está começando: não delegue seu pensamento para LLMs.
Use elas como um rubber duck extremamente capaz. Explique seu raciocínio para elas. Peça para validarem sua lógica. Mas VOCÊ pensa primeiro.
E se você tem 2-5 anos de experiência?
Você já está no caminho certo. Já debugou código em produção. Já refatorou sistemas legacy. Já tomou decisões de arquitetura. Esse mapa mental está se formando.
Não precisa de 10 anos para começar a usar LLMs com eficiência. Precisa do que você já tem: curiosidade, vontade de aprender, e experiência suficiente para reconhecer padrões básicos.
A diferença é que agora você pode acelerar sua curva de aprendizado. Cada projeto com LLMs te ensina mais rápido do que seria possível sozinho.
Arquitetura importa MAIS, não menos
Uma coisa que não mudou: a importância de projetar bons sistemas.
Na verdade, ficou mais importante.
Porque agora é trivial adicionar código. O que não é trivial? Manter o código organizado, testado, observável, evolutivo.
O custo do software não está em escrever código. Está em manter código por anos.
E LLMs só ajudam com a primeira parte. A segunda continua sendo sua responsabilidade.
Sistemas bem arquitetados têm:
Boundaries claros: Cada módulo tem responsabilidade bem definida
Testes abrangentes: Que documentam comportamento e pegam regressões
Observabilidade: Você sabe quando algo quebra, e por quê
Documentação: Contexto para humanos E para LLMs
Esse conhecimento (como projetar sistemas que evoluem bem) não vem de tutoriais. Vem de ter trabalhado em sistemas grandes por anos.
De ter feito refactorings massivos. De ter visto o custo de decisões ruins. De ter aprendido a equilibrar simplicidade com extensibilidade.
Essa experiência é o que separa quem vai dominar essa nova era de quem vai ficar para trás.
Os gargalos que não desaparecem
Vamos falar sobre a parte que muita gente ignora: os limites.
LLMs não resolveram todos os problemas de desenvolvimento de software. Na verdade, alguns problemas ficaram mais evidentes.
Verificação continua sendo cara
Você consegue gerar código 10x mais rápido. Ótimo.
Mas você ainda precisa:
Revisar esse código linha por linha
Testar em cenários que o agente não considerou
Validar que a solução realmente resolve o problema
Garantir que não introduz bugs sutis
E aqui está o ponto: verificação não escala da mesma forma que geração.
Um agente pode escrever 1000 linhas de código em minutos. Você não consegue revisar 1000 linhas com qualidade em minutos.
Então o gargalo mudou. Antes era “quanto código consigo escrever?”. Agora é “quanto código consigo validar com confiança?”.
Empresas que entendem isso estão investindo pesado em:
Testes automatizados robustos: Para pegar regressões rapidamente
Feature flags: Para lançar incrementalmente e limitar blast radius
Observabilidade: Para detectar problemas em produção cedo
Code review criterioso: Mais importante agora, não menos
Product sense é o novo diferencial
Aqui está onde o jogo realmente mudou.
Antes, fazer uma feature era caro. Então você pensava muito antes de construir. Fazia discovery. Validava com usuários. Priorizava cuidadosamente.
Agora? É tentador pular essas etapas. “Ah, é só 30 minutos para implementar, vamos fazer.”
Essa é a armadilha.
Adicionar features ficou barato. Mas features têm custos invisíveis:
Complexidade: Cada feature torna o produto mais difícil de usar
Manutenção: Código que você escreve hoje precisa de manutenção para sempre
Confusão: Muitas opções confundem usuários
Foco: Cada feature que você adiciona dilui seu posicionamento
Os melhores produtos não são aqueles com mais features. São aqueles com as features certas.
E saber quais são as certas? Isso requer:
Entender usuários profundamente: Seus problemas reais, não o que dizem que querem
Dizer não constantemente: A maioria das ideias deve ser rejeitada
Medir impacto: Você construiu, mas resolveu o problema?
Iterar baseado em dados: Ajustar baseado no que funciona, não no que “deveria” funcionar
Dados da McKinsey mostram o gap: 64% das empresas dizem que IA habilita inovação. Mas apenas 39% reportam impacto real no EBIT (lucro operacional).
Por quê? Porque construir é fácil. Construir a coisa certa é difícil.
E essa habilidade (product sense, taste, julgamento) não vem de LLMs. Vem de:
Conversar com usuários
Ver features falharem
Aprender a simplicidade intencional
Desenvolver intuição sobre o que funciona
Como acelerar (sem perder qualidade)
OK, mas e se você quer ser um dos 6% que realmente captura valor com IA?
Algumas práticas que funcionam:
1. Use o plan mode agressivamente
Antes de escrever qualquer código, peça para a LLM:
Quebrar o problema em partes menores
Identificar edge cases
Sugerir ordem de implementação
Apontar riscos potenciais
Esse planejamento custa 5 minutos e economiza horas de refactoring depois.
2. Contexto é tudo
LLMs são tão boas quanto o contexto que você dá. Então invista em:
Documentação clara de arquitetura
READMEs atualizados em cada módulo
Comentários explicando “por quê”, não “o quê”
Exemplos de uso em testes
Isso ajuda humanos E ajuda agentes.
3. Testes primeiro, sempre
Eu sei, eu sei. Todo mundo fala de TDD e ninguém faz. Eu mesmo nunca fui fã.
Mas com LLMs, testes ficaram ainda mais importantes. Porque você está gerando muito código rapidamente.
E a única forma de ter confiança nesse código? Testes robustos que validam comportamento.
4. Itere em ciclos curtos
Não dê tarefas gigantes para o agente. Quebre em partes de 30-60 minutos.
Valide cada parte antes de seguir para a próxima.
Isso evita que você perca 2 horas numa direção errada.
5. Aprenda com feedback rápido
Construa, lance (para um subset de usuários), mede, ajusta.
Não fique 2 meses construindo a feature perfeita. Construa a versão mais simples que resolve 80% do problema, em 20% do tempo.
E então itere baseado em feedback real.
É exatamente isso que separa produtos que encantam de produtos que são apenas “OK”.
Não é sobre ter mais features. É sobre resolver o problema certo, da forma mais simples possível, e continuar melhorando baseado no que aprende.
🌟 Resumo
Fundamentação técnica vale mais agora, não menos: LLMs amplificam seu julgamento. Se seu julgamento é fraco, a amplificação não ajuda. Veteranos dominam essas ferramentas porque têm anos de experiência reconhecendo padrões e tomando decisões de arquitetura.
Você virou eng manager + product manager: Seu trabalho mudou de “escrever código” para “dirigir agentes, validar output, e decidir O QUE construir”. As habilidades mais valiosas agora são: contextualizar problemas, revisar criticamente, e ter product sense para priorizar o que realmente importa.
Os gargalos mudaram: Geração de código ficou barato. Verificação (code review, testes, validação) continua cara. Product sense (saber quais features construir) ficou crítico. Sucesso não é fazer mais features, é fazer as features certas com qualidade.
Ação concreta para esta semana: Escolha UMA feature que você planejava construir. Antes de abrir o editor, gaste 15 minutos planejando com uma LLM: quebre em partes menores, identifique edge cases, pense nos testes. Então implemente usando agentes, mas revise cada linha. Compare a qualidade e velocidade com seu processo normal.
O futuro não é sobre escolher entre “aprender profundamente” ou “usar IA”. É sobre usar IA porque você aprendeu profundamente.
Dan Abramov, criador do Redux e membro do React Core Team, está certo em se preocupar com a educação técnica na era de IA. Mas a solução não é rejeitar essas ferramentas. É usá-las da forma certa: como aceleradores de quem já tem fundamentação, não como substitutas de aprendizado.
Os próximos anos vão separar dois grupos de engenheiros:
Aqueles que usam LLMs como muleta: delegando pensamento, aceitando soluções sem entender, ficando cada vez mais dependentes
Aqueles que usam LLMs como superpoder: amplificando expertise, acelerando execução, construindo coisas que antes eram impossíveis
A escolha é sua.
Mas se você escolher o caminho 2, as oportunidades são ilimitadas. Porque você vai poder construir mais, aprender mais rápido, e ter impacto maior do que qualquer geração anterior de engenheiros.
É o momento mais empolgante para estar em tecnologia. Não apesar de LLMs, mas por causa delas.
Desde que você saiba usá-las da forma certa.
Se esse artigo foi útil pra você, curta ou compartilhe ele com alguém. Me ajude muito. E se você indicar a newsletter para mais pessoas, você também ganha recompensas.
Excelente post!
"Engenheiros experientes (10+ anos) são quem mais se beneficia de ferramentas de IA, não por coincidência, mas porque já possuem o "mapa mental" necessário para direcionar eficazmente essas ferramentas", exatamente o que tenho vindo a discutir com muitas pessoas da area, o meu filho que ainda é junior já o proibi de usar constantemente! É crucial que juniores desenvolvam as bases sólidas sem dependência de LLM, e irá me agradecer quando estiver a trabalhar num projeto que não poderá usar nenhuma inferencia a LLM!
Parabéns por mais uma otima newsletter Lucas!!!