O Engenheiro de Software na Era da IA: o que o Vale do Silício já entendeu e o Brasil ainda não faz

Em 2024, Tobi Lütke mandou um memo interno para todos na Shopify: qualquer pedido de headcount precisaria vir acompanhado de uma justificativa de por que o trabalho não poderia ser feito com IA. O output de produto dobrou. O time encolheu.

Na Klarna, um agente de IA passou a fazer o trabalho de 700 atendentes em tempo real, com índice de satisfação acima da média humana. Na Duolingo, contratos de terceirizados de conteúdo não foram renovados. O trabalho passou para agentes. Na Cursor, dois engenheiros construíram em semanas um produto que chegou a um bilhão de dólares de valuation.

Em todos esses casos, o padrão foi o mesmo: a alavanca do engenheiro de software mudou de lugar.

Por anos, a alavanca era execução: quantas histórias o time entregava por sprint, quantas linhas de código eram produzidas, quantos tickets fechados por semana. O processo todo, daily, refinamento, review, existia para coordenar essa execução.

Com IA acelerando a execução, esse modelo começa a mostrar suas tensões. E o motivo não é óbvio:

Não é que escrever código ficou trivial. É que o custo marginal de escrever código errado despencou. Se antes você perdia duas semanas construindo a feature errada, hoje você perde dois dias, mas ainda assim construiu a feature errada. A velocidade expõe o problema de escopo, não o resolve.

O gargalo deixou de ser “quantas mãos eu tenho” e passou a ser “quão bom é o escopo que essas mãos recebem”.

Neste artigo explico o que mudou, por que contexto virou infraestrutura e o que você pode fazer começando esta semana.

1. Times menores, mais autônomos e com papéis misturados

Durante anos, o modelo padrão de um time de produto era algo assim:

PM → Designer → Tech Lead → 6 a 8 engenheiros

Hierarquia clara. Especialidades bem definidas. Handoffs entre áreas. O engenheiro recebia o ticket refinado, desenvolvia, passava para o QA. Cada um no seu quadrado.

Esse modelo funcionou bem enquanto a principal restrição era execução. O processo sprint, refinamento, daily, retro existia para compensar a falta de autonomia individual. Quanto mais pessoas no loop, mais cerimônia para garantir alinhamento.

A tensão: esse modelo foi desenhado para um mundo onde execução era cara e lenta. Com IA, essa premissa muda de intensidade.

O que o Vale está fazendo diferente

Empresas como Anthropic, Coinbase e dezenas de startups AI-native estão operando com squads de 5 a 6 pessoas e com uma composição radicalmente diferente:

2 Engs + Data Scientist + Designer + PM

Sem Tech Lead dedicado nos primeiros anos. Com role blurring explícito: PMs que abrem PRs, engenheiros que tomam decisões de design, GTM Engineers que misturam desenvolvimento com marketing e vendas.

A Anthropic tem uma política documentada: todo manager começa como IC. Passa 20% do tempo escrevendo código. O critério de liderança não é quantas pessoas você gerencia é o quanto você faz dogfooding real do produto.

Na Coinbase, o mesmo princípio: 20% do tempo de liderança técnica dedicado à execução direta, não à gestão.

O roadmap de 6 meses perdeu utilidade. O modelo é Just In Time planning: norte estratégico claro, decisões tomadas perto da execução, prototipação antes de qualquer especificação detalhada.

O ratio de pessoas por time mudou porque a alavanca mudou. Com IA acelerando a execução, o gargalo deixou de ser “quantas mãos eu tenho” e passou a ser “qual é o escopo de trabalho dessas mãos”.

2. Contexto como infraestrutura o insight menos discutido

Aqui está o ponto que eu considero mais importante e o menos aparente nas discussões sobre IA em tech.

O desenvolvedor com mais alavancagem não é o que escreve mais código. É o que tem mais contexto instrumentado.

O que isso significa na prática?

Pense em como a maioria dos engenheiros recebe trabalho hoje:

Um ticket pré-formatado que passou por PM, PO e Tech Lead
Sem acesso direto a analytics esses dados estão com o PM
Sem conversa com quem levantou o requisito
O contexto de negócio existe, mas está disperso na cabeça de outras pessoas

Agora pense no que acontece quando você coloca IA nesse cenário:

Você entrega mais rápido a coisa errada.

A IA amplifica velocidade de execução. Mas se o escopo está errado, você chegou ao lugar errado mais depressa. É como turbinar um carro com o GPS apontando para o endereço errado.

O que é contexto instrumentado, concretamente?

O engenheiro com contexto instrumentado tem acesso direto a:

Analytics consegue consultar dados de uso sem depender do PM
Réplica de banco de dados antes de escrever uma linha, roda queries para entender volumetria, padrões e edge cases reais
Feedback de usuário agregado não precisa de reunião para saber o que o cliente está reclamando
Logs e dados de erro consegue correlacionar comportamento do usuário com falhas técnicas

Com esse setup, a pergunta muda completamente. Em vez de “como deve ser essa feature?”, o engenheiro pergunta ao agente: “quantos usuários têm mais de 500 itens no histórico?” e a decisão arquitetural de paginação, indexação ou cache sai baseada em dado real, não em achismo.

Contexto instrumentado não é sobre escrever código mais rápido. É sobre tomar decisões melhores antes de escrever qualquer código.

3. O gap real e por que não é falta de ferramenta

Vou ser direto: o gap entre o Brasil e o Vale do Silício não é de acesso a ferramenta.

O Copilot, o Cursor, o Claude qualquer engenheiro no Brasil pode usar hoje. O gap não é de ferramenta. É de autonomia e contexto.

Como é o dia a dia em boa parte das empresas

Ticket refinado que passou por PM, PO e Tech Lead o engenheiro tem pouco espaço para influenciar o escopo
Acesso limitado a métricas ou dados de negócio direto
Pouco contato com quem levantou o requisito
O número de negócio que a feature pretende mover fica na cabeça do PM, não do engenheiro
A IA acelera a execução mas dentro de um escopo que o engenheiro não ajudou a definir

Como é o dia a dia nas empresas AI-native

Acesso direto a analytics e dados de produção como rotina de trabalho
Conversas com PM, designers e clientes fazem parte da rotina do engenheiro
Autonomia para propor e priorizar features não só executar
Contexto de negócio disponível via agente antes de qualquer decisão técnica
Resultado: IA amplifica alavanca real, não velocidade dentro do escopo errado

A diferença não é de 10%. É de 1 a 2 anos de vantagem competitiva que se acumula silenciosamente a cada ciclo de produto.

O ponto mais honesto que posso fazer

Quem só recebe ticket vai entregar código mais rápido mas preso no mesmo escopo.

A IA não vai te dar autonomia que você não tem. Ela não vai te dar acesso a dados que o PM guarda. Ela não vai te colocar numa reunião com stakeholder se ninguém te convida.

O que ela vai fazer é amplificar a alavanca que você já tem. Se a sua alavanca é pequena execução dentro de um escopo bem delimitado você vai executar mais rápido dentro desse escopo. Se a sua alavanca é grande você tem contexto, autonomia, acesso a dados ela vai multiplicar isso.

4. O que fazer a partir desta semana

Você não vai transformar a cultura da sua empresa da noite para o dia. Tentar fazer tudo de uma vez é o caminho mais rápido para o burnout sem resultado.

Mas você pode começar com quatro movimentos concretos:

1. Peça acesso a analytics e dados de produção

Não como exceção eventual, mas como ferramenta de trabalho padrão. Entender as queries que o PM usa para tomar decisão é o primeiro passo para tomar essas decisões junto e defender sua própria perspectiva técnica com dados.

2. Fale com um stakeholder antes de codar

Na próxima feature, antes de abrir o editor, marque 20 minutos com quem levantou o requisito. Pergunte diretamente: “qual métrica de negócio esta feature pretende mover?”. Você vai se surpreender com o quanto isso muda o escopo do que você vai construir.

3. Instrumente contexto na sua IA

Explore ferramentas como MCPs conectados ao banco, logs de erro e feedback de usuário integrados no seu agente. O objetivo não é ter mais features no Cursor é conseguir fazer perguntas de negócio antes de tomar decisões técnicas.

4. Guie, não empurre

Se você é sênior ou tech lead, somos agentes de mudança cultural mas essa mudança não acontece por decreto. Acontece em pequenos passos consistentes. Demonstre o modelo, documente o resultado, convide a equipe a replicar. Em três a seis meses de evolução constante, o resultado aparece e se torna difícil de ignorar.

Conclusão

O modelo de times grandes, com silos de especialidade e processos que compensam falta de autonomia, foi desenhado para um mundo onde execução era o gargalo. Esse mundo está se transformando rápido.

A nova alavanca é contexto. Times menores, com papéis misturados e acesso direto ao problema real, conseguem usar IA de forma que amplifica escopo de produto não só velocidade de código.

O Brasil tem os engenheiros. Tem as ferramentas. A diferença, no momento, está em construir autonomia e contexto instrumentado.

Comece esta semana.