❝ “Fabrício, o sistema está lento. A TOTVS recomendou aumentar o servidor. Vamos investir R$ 200 mil em hardware novo.”

❝ “Fabrício, o ambiente tá lento. O fornecedor sugeriu subir mais 8 vCores no Azure SQL. Vai aumentar uns R$ 12 mil/mês na fatura, mas precisamos.”

1. Uma só query pode comer 40% do servidor (ou da sua fatura cloud)

Nos clientes que atendi, era comum encontrar uma única query consumindo 30% a 40% de todo o recurso do banco. Subir o SKU da instância não resolve isso — só faz a query consumir 40% de uma máquina mais cara. Em cloud, isso vira aumento mensal recorrente. Identificar e otimizar essa query, sim, libera o ambiente inteiro — e na cloud derruba a fatura.

2. Sem visibilidade, você vive no escuro

Sem ferramenta de monitoramento, ninguém sabe qual query é cara, qual tabela cresce mais, ou onde estão os locks. Você vive reagindo a chamado de usuário. Esse é o sintoma clássico que faz aprovar mais infra (ou subir o SKU na cloud): quando ninguém enxerga o problema, “trocar tudo” vira a melhor hipótese possível. Não é.

3. SELECT * é o inimigo número 1 da performance

Quando uma query pede “todas as colunas” de uma tabela gigante, o SQL Server desiste de usar índice e lê a tabela inteira. Em tabelas do Protheus com 48 milhões de linhas, isso significa milhões de leituras desnecessárias. Pedir só as colunas necessárias muda tudo.

4. Índices nos JOINs, não só nos filtros

A maioria dos DBAs cuida bem dos índices nos filtros (WHERE). Mas quando uma query junta 3 tabelas grandes do Protheus, e os índices nas colunas de junção não existem, o servidor inteiro trava. Esse é o gargalo mais subestimado que existe — e raramente aparece em diagnóstico de fornecedor.

5. Compressão pode reduzir o banco em 70% (e não é gambiarra)

O Protheus preenche colunas vazias com espaços em branco em vez de NULL — desperdiçando espaço massivamente. A compressão nativa do SQL Server elimina esses vazios, com reduções reais entre 60% e 80% — vi cliente sair de 242GB pra 50GB. Banco menor cabe na RAM, e aí tudo fica mais rápido. Sem mexer no ERP, sem novo servidor.

❝ “Comprar hardware adia. Cloud cobra todo mês. Performance no banco de dados resolve.”

❝ “Quando ninguém enxerga onde está o gargalo, ‘trocar tudo’ sempre parece a melhor opção.”

❝ “O servidor mais caro do mundo — e o SKU mais alto da Azure — não consertam uma query mal escrita.”

Case 1 · CT2010 (48 milhões de registros)

O índice sugerido nem sempre é o melhor

Query filtrava por uma coluna específica. O próprio SQL Server sugeriu um índice gigante — seria caro de manter numa tabela desse tamanho. Solução: um índice menor, apenas pela coluna seletiva (420MB, criado em 5 minutos):

Antes 5,7s 91.143 leituras · CPU 10s

Depois 0,07s 4 leituras · CPU 0ms

A lição pro gestor: não aceite cegamente o índice sugerido pelo SQL nem o “precisa de mais máquina” do fornecedor. Diagnóstico bem feito é outra coisa.

Case 2 · SD2010 (TempDB sob pressão)

Quando o disco está lento, o problema raramente é o disco

Cliente com query escrita de forma que o SQL despejava 86 milhões de leituras no TempDB pra cada execução. Sintoma visível: disco lento, servidor “travado”. O fornecedor recomendou storage Premium na Azure — o que significaria uns R$ 8 mil/mês a mais na fatura. Solução real: 1 índice estratégico cobrindo o padrão das subqueries:

Antes 4m 05s 86M tempdb · CPU 362s

Depois 3s 4.504 tempdb · CPU 12s

A lição pro gestor: sintoma de hardware (disco lento) raramente tem causa de hardware. Storage Premium só faria os 86M de leituras serem mais rápidos — sem resolver nada, e com R$ 8 mil/mês a mais na fatura, pra sempre.

Case 3 · SC5 + SC6 + SC9 (Pedidos)

Locks travando o banco inteiro

Query com JOINs em 3 tabelas de Pedidos do Protheus. Realizava 481 milhões de leituras e — o pior — causava locks que travavam outros processos do banco. O cliente já tinha aprovado um upgrade de servidor de R$ 280 mil que se tornou desnecessário. Solução: 3 índices estratégicos focados nas colunas de JOIN:

Antes 2m 40s 481M leituras · locks

Depois 4s Locks eliminados

A lição pro gestor: R$ 280 mil em hardware não acabariam com os locks — locks são problema lógico, não físico. 3 índices, sim.

Case 4 · Query rodando 15 minutos

Uma função no WHERE matando o índice

Query do ERP demorando 15 minutos pra rodar. Causa: o filtro usava SUBSTRING numa coluna de data — o que força o SQL a aplicar a função linha por linha, lendo a tabela inteira. Solução: reescrever o filtro sem função + criar índice. Resultado:

Antes 15 min Table Scan completo

Depois segundos Seek no índice

A lição pro gestor: 15 minutos virando segundos não é mágica nem hardware — é reescrita de uma linha de código + 1 índice. Trabalho de horas, não de meses.

Quer ver mais? Esses 4 são uma amostra. Tenho um post separado com 10 cases reais de melhoria de performance no Protheus →

✓ Comprar hardware adia. Cloud cobra todo mês. Performance no banco resolve.
✓ Uma só query pode comer 40% do servidor (ou da fatura cloud)
✓ Sem visibilidade, “subir o SKU” sempre parece a melhor opção
✓ SELECT * é o inimigo número 1 da performance
✓ Índices nos JOINs são tão importantes quanto nos filtros
✓ Compressão pode reduzir o banco em 70% sem mexer no ERP
✓ Disco lento raramente é problema de disco
✓ Diagnóstico bom dura horas. Infra errada dura anos — e na cloud, fatura todo mês.

⚙️ Guia Técnico · Para Profissionais de TI

Vídeos processados: 19 (+10h)  ·  Leitura: ~20 min

Interleaved thinking com tool use

Claude agora alterna entre pensar e chamar ferramentas. Antes, com Claude 3.7, todo o raciocínio era feito no começo. Agora ele pensa, executa, analisa o resultado, pensa de novo.

Implicação prática: agentes de horizonte longo detectam erros no meio do caminho e ajustam plano. Você pode orientar o quê Claude deve pensar entre chamadas ("reflita sobre a qualidade dos resultados antes de seguir").

Parallel tool calling

Com 3.7 era uma ferramenta por turno (frustrantemente lento). Com Claude 4, o modelo declara 8 chamadas de ferramentas em paralelo no mesmo objeto de resposta.

Economia de tokens e latência: um agente que fazia 8 chamadas sequenciais agora faz em 1 rodada. Menos ciclos de planning-act.

Memória externa (file-based)

Quando você dá ao Claude um sistema de arquivos pra ler/escrever, ele rastreia progresso ao longo de horas. Prova: Claude Opus 4 jogou Pokémon por 12h contínuas mantendo um plano de treinamento em arquivo (64 batalhas consecutivas).

Implementação: exponha uma ferramenta de leitura/escrita de arquivos e instrua Claude a criar seu próprio workspace de memória.

Instruction following + reward hacking -80%

O system prompt do Claude.ai caiu de 16k pra 4.8k tokens (-70%). Isso é porque Claude 4 segue instruções bem melhor em prompts longos (10k+ tokens).

Reward hacking (trapacear pra passar no teste): 80% menos em benchmark interno. Menos necessidade de revisar cada linha.

🎯 Qual modelo usar?

Opus 4 — Código em base grande/complexa, migrações, refatorações, agentes de horizonte longo, planejamento e orquestração.

Sonnet 4 — Rápido e eficiente. Greenfield coding, vibe coding, qualquer caso com humano no loop.

Regra prática: se Sonnet 3.7 acerta 60-70% na sua eval, hora de testar Opus 4.

⚠️ Ao migrar de 3.7: Claude 4 é menos over-eager por padrão. Se você tem frases tipo "faça só o que eu pedi" no system prompt, remova. Se você quer que ele vá além do pedido, diga explicitamente.

🔧 Arquitetura por baixo dos panos

O Claude Code não faz nenhuma indexação, não usa RAG, não sobe seu código pra lugar nenhum. É um agente puro com três ferramentas simples:

◦ Ferramentas de arquivo (criar/editar)
◦ Bash terminal
◦ Agentic search (grep, find, glob)

Vantagens: zero setup, código fica local, modelo decide em tempo real o que buscar (usando o mesmo método que um dev novo usaria pra explorar uma base).

Dica #1 do Boris (criador)

Começa pedindo perguntas sobre a base de código

Na Anthropic, onboarding técnico caiu de 2-3 semanas pra 2-3 dias. Novos devs passam o primeiro dia só fazendo perguntas sobre a base.

Exemplos de perguntas boas:

◦ "Onde essa feature está implementada?"
◦ "Olha o git log dessa função e me conta por que os argumentos são esquisitos"
◦ "Como essa classe é instanciada? Me mostra exemplos"
◦ "O que eu shipei essa semana? Usa git log e meu username"

🛠️ Workflow recomendado

1. Explora → planeja → pede aprovação → codifica.

Em vez de pedir "implementa essa feature de 3k linhas", peça: "faz um plano, não escreve código ainda, roda por mim, pede aprovação antes de executar".

2. Dê uma forma dele verificar o próprio trabalho.

Unit tests, screenshots via puppeteer, iOS simulator. Se Claude vê o resultado, ele itera sozinho 2-3 vezes e quase sempre chega perto do perfeito.

📄 CLAUDE.md — o arquivo de memória do projeto

Arquivo especial lido automaticamente no início de cada sessão. Hierarquia:

◦ Enterprise policy — config global do time inteiro (enterprise route)
◦ Home directory — preferências pessoais
◦ Project root — checkin no git, compartilhado com o time
◦ CLAUDE.local.md — pessoal, não commitado
◦ Subdiretórios aninhados — só carrega quando Claude trabalha naquela pasta

O que colocar: comandos bash comuns (npm test, rake test), style guide, arquivos críticos, MCPs em uso, arquitetura em 1 parágrafo. Mantenha curto — se fica muito longo, consome contexto à toa.

⌨️ Atalhos essenciais

◦ Shift + Tab — auto-accept mode (edições sem confirmação)
◦ Escape — interrompe Claude no meio, você redireciona (seguro, não corrompe sessão)
◦ Escape + Escape — volta no histórico (feature escondida)
◦ # + texto — "lembra disso" — adiciona no CLAUDE.md
◦ ! + comando — modo bash, comando vai pro contexto
◦ Ctrl + R — mostra todo o output (mesmo que Claude vê)
◦ /compact — resume sessão longa, continua com contexto comprimido
◦ /clear — apaga tudo menos CLAUDE.md
◦ /memory — mostra todos os memory files ativos
◦ /resume — retoma sessão anterior
◦ --continue — flag pra continuar na inicialização

🌐 Context management

Claude tem janela de 200k tokens. Você vai atingir esse limite em sessões longas. Quando aparecer o warning no canto inferior direito:

Opção A: /clear se você terminou um chunk de trabalho e vai começar outro não-relacionado.

Opção B: /compact — Claude resume a sessão inteira como se fosse passar pra outro dev. A nova sessão começa com esse sumário e você continua. Essa funcionalidade foi pesadamente tunada pra não perder contexto importante.

🧠 Pro tips do Boris

Dictation no macOS. System Preferences → Accessibility → Dictation. Dois toques na tecla de dictation e você fala o prompt. Muito mais rápido pra prompts longos.

Múltiplos Claudes em paralelo. Use tmux ou abas. Cal conta que conhece gente rodando 4 simultaneamente. Ele mesmo só consegue gerenciar 2.

Pense antes, codifique depois. Escreva "think hard" no prompt pra ativar pensamento estendido visivelmente (texto cinza).

Commit automatizado. Em vez de escrever mensagem de commit você mesmo: "commit e push pra branch, abre PR". Claude procura padrões no git log pra formatar igual.

📝 As 10 partes

1. Task context — papel e tarefa
2. Tone context — objetivo? Criativo? Cauteloso?
3. Background data — conteúdo dinâmico
4. Detailed instructions — passo a passo
5. Examples — input/output esperado
6. Conversation history — se houver
7. Immediate task — tarefa atual
8. Thinking — pensar passo a passo antes
9. Output formatting — JSON? XML? Markdown?
10. Prefilled response — pré-começar a resposta

🔧 Use XML tags sempre

Claude foi treinado pra reconhecer XML. Delimite seções:

<instructions>
Analise o formulário e dê um veredito.
</instructions>

<form>
[conteúdo]
</form>

<final_verdict>
[Claude responde aqui]
</final_verdict>

Bônus: trivial extrair só a parte que interessa via regex/parse.

💬 Prefill — "palavras na boca do Claude"

Quer saída JSON garantida? Comece a resposta dele com {.

Quer uma XML tag específica? Comece com <final_verdict>.

Claude continua no formato. Elimina preamble "Claro! Vou ajudar você…" e garante output estruturado.

🧠 Extended thinking como ferramenta

Em vez de "pense passo a passo" dentro do prompt, ative o thinking mode. Claude gera um bloco separado, mais eficiente em tokens, e você pode inspecionar o raciocínio.

Budget control: você define máximo. Modelo adapta até esse limite (não passa, mas pode ficar bem abaixo se não precisar).

Instrua o thinking: "ao pensar, primeiro considere qual fonte consultar, depois como estruturar" — muito melhor que instrução genérica.

✅ 4 critérios pra decidir se usa agente

1. Complexidade — Consegue descrever passo a passo? Então não precisa de agente. Use workflow.
2. Valor — Agente consome muito token. Baixo valor? Abandone.
3. Ferramentas viáveis — Consegue dar ao agente o que ele precisa? Se não, restrinja o escopo.
4. Custo de erro — Erro irrecuperável? Coloca humano no loop.

🛠️ Construindo o prompt do agente

Comece simples. Não perca tempo escrevendo o prompt perfeito de primeira. Pergunta curta, veja o que falha, itera.

Não use few-shot examples tradicionais. Limitam demais os modelos de fronteira. Dê exemplos de como pensar, não inputs/outputs exatos.

Não peça "pense passo a passo". Redundante — modelos modernos já fazem. Em vez disso, oriente o quê pensar.

Permita tool calling paralelo explicitamente no prompt quando souber que várias ferramentas são independentes.

📊 Como avaliar

◦ LLM as judge — outro Claude avalia contra uma rubrica. Robústo a variações semânticas.
◦ Tool precision — verifica programaticamente se as ferramentas certas foram usadas.
◦ Tau-bench — verifica estado final correto do sistema (banco atualizado, arquivo modificado, etc).
◦ Nada substitui revisão humana de transcrições.

Python em contêineres isolados

Claude escreve Python, contêiner dedicado da Anthropic executa, retorna stdout/stderr/arquivos gerados. Cada organização tem contêineres isolados.

Setup:

tools: [
  { type: "code_execution_20250522", name: "code_execution" }
]

50 horas de contêiner grátis. Depois escala com pricing.

Busca agêntica com citações

Não é uma query só. Claude decide quantas buscas, quando aprofundar, quando parar. Retorna com citações automáticas (footnotes em cada fato).

Parâmetros úteis: allowed_domains (restringe fontes) e max_uses (limita turnos pra conservar tokens).

MCPs remotos direto na API

Declare MCP servers (Asana, Zapier, Gmail, GitHub, etc) no parâmetro mcp_servers:

mcp_servers: [
  {
    type: "url",
    url: "https://mcp.asana.com/sse",
    name: "asana",
    authorization_token: "Bearer xxx"
  }
]

Demo do Brad: agente buscou tarefas no Asana, gerou imagem via Cloudflare MCP, enviou email via Zapier — uma única chamada API. MCPs disponíveis: Asana, Zapier, PayPal, ElevenLabs, Pulumi, Docker e vários outros.

💰 Otimização de custos

◦ Prompt caching — -90%. Agora com TTL de 1 hora (era 5 min).
◦ Batch processing — -50%. Suporta web search, code exec, MCP.
◦ Priority tier — compre capacidade mensal com 99% de reliability.

1. Prompts (user-driven)

Templates predefinidos que o usuário invoca ativamente. Aparecem como slash commands no cliente. Você, autor do MCP server, sabe usar melhor — então prepare prompts de exemplo com autocompletar paramétrico.

2. Resources (app-driven)

Dados brutos que o aplicativo decide como usar. Pode virar contexto direto, pode virar embedding+RAG, pode expor como file-like object. Área pouco explorada segundo David.

3. Tools (model-driven)

Ações que o modelo invoca quando decide. 99% dos MCP servers só fazem isso.

Uso como ferramenta Unix

$ cat error.log | claude -p "resuma as falhas"
$ ifconfig | claude -p "explica essa saída"
$ claude -p "escreve Fibonacci em Python" --allow-tools write
$ claude -p "query" --output-format json | jq '.response'

Integra em qualquer pipeline Unix. SDKs Python e TypeScript também disponíveis.

🚀 Claude GitHub Actions (open source)

Mencione @claude em issue ou PR. Ele:

◦ Lê o código do projeto
◦ Cria PRs a partir de issues
◦ Responde perguntas técnicas no GitHub
◦ Revisa código
◦ Adiciona commits em PRs existentes

Instalação: /install-github-action no Claude Code do seu repo. Ele gera o YAML e configura.

🛠️ Casos de uso do SDK

◦ CI/CD — Claude revisa cada PR antes dos humanos
◦ Triagem de bugs — classifica issues por prioridade
◦ Chatbot customizado — assistente interno com Claude Code por trás
◦ Análise de logs — pipeline que resume erros críticos diariamente
◦ Migrações de código em escala
◦ Geração de testes para cobertura

🔒 Permission request tool (novo)

Em vez de pré-configurar --allow-tools estaticamente, você pode delegar a decisão pra um MCP server que pergunta em tempo real ao usuário.

Útil quando você não sabe antecipadamente quais ferramentas Claude vai querer usar.

📈 A curva exponencial

Duração das tarefas que IA consegue fazer dobra a cada 7 meses. Hoje ~1h. Ano que vem, 1 dia. Ano seguinte, 1 semana.

Não vai ter como você ler cada linha. Alternativa: aprender a delegar com confiança.

1. Esqueça o código, não o produto

Analogia do compilador: você sabe que tem assembly lá embaixo, mas não precisa ler. Confia e foca no produto. Com IA, vai ser igual.

2. Ache uma camada de abstração verificável

Esse é problema antigo:

◦ CTO gerencia especialista → testes de aceitação
◦ PM revisa feature → usa o produto
◦ CEO confere contador → spot check

3. Foque em "leaf nodes"

Partes do código que nada depende delas. Dívida técnica nelas é aceitável. A arquitetura central precisa ser entendida por humanos — tudo mais depende dela.

4. Seja o PM do Claude

"Ask not what Claude can do for you, but what you can do for Claude."

Erik gasta 15-20 minutos coletando contexto antes de pedir implementação. Numa conversa separada, Claude explora a base, identifica arquivos, construímos o plano juntos. Depois passo o plano em um novo contexto pra executar.

Case real — Anthropic

22.000 linhas escritas pelo Claude em produção

O time de RL da Anthropic mergou +22k linhas -0 feitas majoritariamente pelo Claude. O processo:

✓ Dias de trabalho humano planejando requisitos
✓ Concentrado em leaf nodes
✓ Partes importantes tiveram revisão humana pesada
✓ Stress tests desenhados pra verificar estabilidade sem ler código
✓ Inputs/outputs desenhados pra serem verificáveis por humanos

🛒 Shopify Roast

Lançaram open source o Roast — framework pra workflows determinísticos + Claude Code. A sacada: combinar passos determinísticos ("sempre rodar type check") com passos não-determinísticos ("pede pro Claude consertar").

Features importantes:

◦ Salvar estado da sessão — não precisa refazer passos 1-4 só pra debugar o 5
◦ Cache de function calls — mesmo conjunto de dados não é re-processado
◦ Estilo Rails (convenção sobre configuração)
◦ Bypass de permissões em modo de prototipagem

Usado pra: migrações de código em escala, aumentar cobertura de teste, pipelines de CI/CD.

📄 Sourcegraph AMP

A Sourcegraph atende 7 das 10 maiores empresas de software do mundo. Eles reconstruíram o agente de coding (AMP) do zero em volta do MCP, em vez de plugar MCP depois.

Arquitetura: MCP como primitivo central (prompts, resources, tools) + proxy remoto que protege conexões e lida com segredos. Demo: bug fix num issue linear, usando MCP do Linear pra buscar, agentic search pra localizar código, ferramenta de edição pra corrigir.

🎯 Guia Estratégico · Para Gestores de TI

Vídeos processados: 19 (+10h)  ·  Leitura: ~15 min

📈 Dado central

A duração das tarefas que a IA consegue fazer está dobrando a cada 7 meses

Hoje a IA faz tarefas que levam cerca de 1 hora de trabalho. Ano que vem, será o equivalente a 1 dia. Em 2 anos, 1 semana inteira.

A analogia usada pelo Erik da Anthropic: o que seria a rotina de um engenheiro se um computador fosse 1 milhão de vezes mais rápido que hoje? Foi exatamente isso que aconteceu nos últimos 20 anos.

Case real — Anthropic

22.000 linhas de código em produção, escritas pelo Claude

Um time interno da própria Anthropic mergeu uma mudança de 22 mil linhas de código escrita majoritariamente pelo Claude, em produção.

O que seria 2 semanas de trabalho humano virou 1 dia. O time acabou com o mesmo nível de confiança que teria com código 100% manual.

A descoberta mais importante do case não foi a economia de tempo. Foi a mudança mental: "coisas que levavam 2 semanas agora levam 1 dia — então vamos fazer mais coisas que antes não consideraríamos".

📈 Ganhos concretos do Claude 4 vs anterior

✓ Claude 4 reduz em 80% a tendência de "trapacear" em testes (hardcodar resposta)
✓ Em uma base de código complexa da própria Anthropic, o sistema de instruções caiu 70% em tamanho
✓ Onboarding técnico na Anthropic caiu de 2-3 semanas pra 2-3 dias
✓ Claude consegue manter foco em planos de +12 horas contínuas de trabalho

"Coding vai embora primeiro. Engenharia de software depois."

Dario fez uma separação importante:

◦ Coding (escrever código, debug, criar funções) → vai ser 95% feito por IA
◦ Engenharia de software (design de sistema, arquitetura, definir o quê construir) → ainda vai exigir humanos por mais tempo

Implicação: o valor do dev vai migrar de "quem escreve código" pra "quem pensa o que deve ser construído e garante qualidade". O papel do engenheiro vira mais próximo do papel que hoje é de arquiteto de software e tech lead.

📈 A lógica da vantagem comparativa

Mesmo que a IA faça 95% da tarefa e você faça só 5%, o resultado é você virar 20x mais produtivo.

O que importa é quais 5% você traz — e esses 5% são exatamente as partes que hoje consomem mais tempo (decisões de arquitetura, entender requisitos reais, garantir qualidade).

📈 Quando o custo de produzir software cai pra perto de zero

Dario fez uma pergunta-chave pra executivos:

"É um artigo de fé da nossa indústria assumir que software só vale a pena se milhões de pessoas usarem. Ou pelo menos centenas de milhares. Mas e quando criar um software customizado pra um único evento custar 20 centavos e 10 segundos? O que isso faz com o papel do dev? Com o papel de empresas de software? Com o papel de startups?"

A resposta dele: "Eu não sei. E acho que ninguém sabe ainda. Mas é a pergunta mais importante que CEOs e gestores deveriam estar fazendo."

🚀 "Abrace as exponenciais"

A frase que todo palestrante repetiu. Não é só que os modelos vão melhorar — é que vão melhorar mais rápido do que a sua intuição espera.

Para CEOs e gestores de TI: não planeje com base em "onde a IA está hoje". Planeje com base em "onde ela vai estar daqui a 12 meses, quando meu projeto de adocacao entrar em produção".

Ganhos de produtividade reportados pelas empresas

⚠️ Observação importante: nenhum desses ganhos foi automático. Todos os cases envolveram investimento em treinamento do time, criação de padrões internos (como o CLAUDE.md) e pelo menos 15-20 minutos de preparação de contexto por tarefa complexa.

"Não pergunte o que o Claude pode fazer por você. Pergunte o que você pode fazer pelo Claude."

O que isso muda na prática

O dev deixa de ser quem executa a tarefa e passa a ser quem prepara o contexto e verifica o resultado. É essencialmente o papel de um gerente de produto, mas aplicado a um "funcionário" que é o Claude.

O que o dev precisa aprender:

◦ Escrever requisitos claros
◦ Identificar e documentar contexto não-óbvio
◦ Criar casos de teste robustos
◦ Revisar output em alto nível (não linha por linha)
◦ Saber quando NÃO confiar na IA (tarefas críticas, arquitetura central)

Erik compara com gerência tradicional:

◦ Um CTO não lê todo código dos times dele — ele faz spot check e confia em testes
◦ Um PM não implementa as features — ele usa o produto pra validar
◦ Um CEO não faz os cálculos — ele verifica pontos-chave do modelo financeiro

Dev "PM do Claude" é a mesma lógica aplicada ao código.

⚠️ Alerta do próprio CEO da Anthropic

Usar IA do jeito errado faz a equipe perder habilidades

Dario admitiu publicamente: "A Anthropic rodou estudos internos que mostram que, dependendo de como você usa IA pra coding, você perde habilidades."

Ele citou o exemplo de alunos que usam IA pra escrever redação: estão basicamente trapaceando no dever, e isso deteriora a capacidade de pensamento estruturado.

Como evitar deskilling no time de TI

✅ Use IA pra amplificar, não substituir o pensamento — o dev ainda precisa entender a arquitetura
✅ Revisão humana obrigatória em arquitetura central — deixe IA fazer "leaf nodes", humano continua na parte crítica
✅ Treinamentos regulares sem IA — fundamentos de algoritmos, design de sistema
✅ Cultura de curiosidade — pergunte "por que Claude fez assim?", não "funciona, partiu mergear"
✅ Pensamento crítico — sempre validar se o código realmente resolve o problema

🎓 Preocupação específica com devs juniores

Se juniores nunca passam pelo processo de quebrar a cabeça e entender arquitetura antes de pedir pra IA resolver, o risco de deskilling é maior. Eles podem produzir resultado, mas sem construir a base de conhecimento que fica pra vida inteira.

Recomendação: estabeleça um "regime de aprendizado" pra devs nos primeiros 6 meses — algumas tarefas sem IA, tempo de pair programming com seniores, revisão crítica do que a IA entrega.

🎨 Canva — prototipagem interna & Canva Code externo

Uso interno: times de produto usam Artifacts do Claude pra criar protótipos clicáveis em minutos. Antes, esse processo levava dias de trabalho com engenheiros. Agora qualquer PM ou designer consegue validar ideias e testar com usuários rapidamente.

Uso externo: lançaram Canva Code, onde usuários sem conhecimento técnico descrevem o que querem e Claude gera aplicações funcionais que podem ser publicadas com 1 clique. Democratizou desenvolvimento pra os +300 milhões de usuários.

🛒 Shopify — framework de automação (Roast)

Criaram e lançaram open source um framework chamado Roast, que combina passos determinísticos ("sempre rodar esses testes") com passos agênticos ("pede pro Claude analisar o resultado e consertar").

Aplicações: migrações de código em larga escala, aumentar cobertura de teste, pipelines de revisão de PR automática. O CTO comentou que está "se espalhando como fogo na palha" dentro da Shopify.

📄 Sourcegraph — repensou o produto inteiro

A Sourcegraph atende 7 das 10 maiores empresas de software do mundo. Quando viram o poder dos agentes, fizeram uma decisão radical: reconstruir o produto do zero em volta da arquitetura de agentes, em vez de tentar plugar IA no que já existia.

O CTO argumenta que empresas com produtos legados precisam fazer a mesma pergunta: "se estivéssemos começando hoje, com IA disponível, construiríamos a mesma arquitetura?"

🔧 Tempo Labs — PMs e designers codando

Startup que criou uma IDE que parece Figma mas edita código real. O resultado: designers abrem PRs direto, sem precisar envolver engenheiro pra ajustes de front-end.

Número reportado: 10-15% dos PRs de front-end nos clientes são abertos por designers ou PMs. O engenheiro só revisa, não escreve.

💡 Padrão comum entre os cases

Nenhuma dessas empresas usa IA como "ferramenta à parte". Todas repensaram processos ou produtos pra incorporar IA no core. O dev vira PM do Claude, o designer vira design engineer, o PM vira protótipador. As fronteiras de papel se borram.

✅ Adote ao longo dos próximos 90 dias

✓ Claude Code pra devs (ganho imediato em onboarding e bug fixes)
✓ CLAUDE.md em todos os projetos principais — padroniza contexto pro time
✓ Claude GitHub Actions pra revisão automática de PRs
✓ Treinamento estruturado do time — o ganho de produtividade não é automático
✓ Políticas claras de onde pode/não pode usar IA (dados sensíveis, segurança, compliance)
✓ Migração pra Claude 4 onde estiver usando Claude 3.7

📅 Planeje pros próximos 6 meses

✓ Agentes para processos internos — triagem de suporte, análise de logs, relatórios
✓ MCP servers internos que expõem ferramentas do seu sistema pro Claude
✓ Migrações de código legado que vinham sendo postergadas
✓ Evolução dos papeis — devs começam a atuar mais como arquitetos/PMs do Claude
✓ Métricas de produtividade pra medir o ganho real no time
✓ Reavaliar arquitetura de produtos principais: precisa ser repensada pra era de agentes?

🚀 Monitore pros próximos 12+ meses

✓ Autonomia de agentes crescendo (de 1h pra 1 dia pra 1 semana de tarefas)
✓ Ferramentas mais robustas — vamos ver IDEs, debugadores, revisores repensados
✓ Redefinição do papel do dev — de implementador pra arquiteto
✓ Redução drástica no custo marginal de criar software
✓ Novos modelos de negócio que só fazem sentido quando código vira barato

1. Pensamento crítico (a nº 1 segundo Dario)

Num mundo onde IA gera texto, imagem, vídeo e código em massa — saber diferenciar real de fake, não cair em golpes, não ter crenças falsas é a habilidade de sobrevivência fundamental. Pra times: contratar e desenvolver pessoas com essa capacidade.

2. Fazer as perguntas certas

Erik amplia: "pessoas totalmente sem conhecimento técnico não vão conseguir usar IA bem, porque não conseguem fazer as perguntas certas. E o dev que deixa de fazer boas perguntas se torna apenas um digitador que a IA substitui." Priorize seniores que guiam, não que executam.

3. Habilidades "human-centered"

Relações, liderança, cuidado. Dario acredita que são as que mais demoram pra ser substituídas. Pra TI: a liderança de time, mentoria, gestão de stakeholders continua sendo fundamental.

4. Mistura digital + físico

Profissões que combinam mundo físico com análise (exemplo dele: radiologista). Pra TI: dev que combina TI com conhecimento de indústria específica (saúde, finanças, logística) fica mais valorizado.

❌ O que fica menos valioso

◦ Escrever código seguindo receita
◦ Tarefas repetitivas e rotineiras
◦ Ser "especialista em uma sintaxe" sem visão sistêmica
◦ Ser o "humano que conecta sistemas" (agentes fazem isso)

🛡️ Riscos que precisam de política

◦ Dívida técnica invisível — Erik enfatizou: "hoje não temos como validar dívida técnica sem ler o código". Se você fizer "vibe coding" em todo lugar, pode acumular dívida que só vai aparecer em 12 meses.
◦ Código gerado em base de código legada — arquitetura central precisa ser verificada por humanos
◦ Segurança e compliance — dados sensíveis só podem ser expostos a IA em ambientes controlados
◦ Reward hacking — embora 80% menor no Claude 4, ainda existe. Testes bem desenhados continuam críticos

👤 Riscos de pessoas

◦ Deskilling — time perde capacidade sem perceber
◦ Resistência à adoção — devs seniores que veem IA como ameaça
◦ Over-adoção — usar IA pra tudo, incluindo onde não faz sentido
◦ Falta de treinamento — ganho de produtividade não vem automático

📝 Itens de política interna que vão ter que existir

◦ Que modelos podem ser usados, com que dados, em que projetos
◦ O que precisa passar por revisão humana antes de mergar
◦ Critérios de qualidade pro output da IA (testes, coverage, tipo safety)
◦ Quem autoriza uso em sistemas críticos
◦ Como gerenciar segredos e acessos em MCP servers
◦ Processo de auditoria de código gerado por IA

🎧 Resumo de Palestra

Palestra original: 1h 3min  ·  Leitura deste resumo: 10 min

A qualidade da sua comunicação é determinada por 3 fatores, nessa ordem de importância:

K (Knowledge) e P (Practice) são o que mais importa. O t (talent) é minúsculo — quase irrelevante.

Não comece com uma piada

No começo a plateia ainda está guardando laptops, se ajustando à sua voz, se acomodando. Piadas no início não funcionam. Elas morrem.

Comece com uma promessa de capacitação

Diga pra plateia o que eles vão saber ao final da palestra que não sabiam no começo. É o motivo deles estarem ali.

Cycling (Repita sua ideia 3 vezes)

Fale sua ideia. Fale de novo. E fale uma terceira vez. Não porque a plateia é burra — mas porque sempre tem uns 20% desatentos em cada momento. Repetindo 3x você alcança todo mundo.

Construa uma cerca ao redor da sua ideia

Explique sua ideia comparando com o que ela não é. "Meu algoritmo parece com o do Jones, exceto que o dele é exponencial e o meu é linear." Isso deixa claro onde sua ideia se encaixa e evita confusão com ideias parecidas.

Pontuação verbal (marcos de retorno)

Crie pontos explícitos onde os desatentos podem "voltar pro ônibus". Enumere. Diga "primeiro…, segundo…, agora o terceiro ponto…". Isso cria costuras visíveis na palestra.

Faça uma pergunta

Uma pergunta faz todo mundo acordar. Regras:

◦ Não pode ser óbvia demais (gera constrangimento)
◦ Não pode ser difícil demais (ninguém responde)
◦ Espere até 7 segundos por uma resposta — parece uma eternidade, mas é o tempo certo

"Case" o lugar antes (tipo ladrão de banco)

Sempre que vai palestrar em algum lugar, Winston pede pro anfitrião levá-lo ao local primeiro. Pra identificar qualquer esquisitice antes de estar sob pressão.

E a sala: não precisa estar lotada, mas tem que estar mais da metade cheia. Salão vazio faz a plateia pensar "o que tem de mais interessante acontecendo em outro lugar?"

Use quadro (não slides)

Três razões:

✓ Qualidade gráfica — você pode desenhar
✓ Velocidade certa — você escreve na velocidade em que as pessoas absorvem ideias
✓ Alvo pras mãos — dá onde apontar

Sobre as mãos: muitos palestrantes ficam de repente conscientes das próprias mãos. Enfiam nos bolsos (considerado ofensivo em alguns países). Põem atrás das costas (ainda pior — historicamente sinal de arma escondida).

Apontar pro quadro resolve o problema — mesmo que você aponte pra coisas que não têm nada a ver com o que está dizendo.

Slides: sempre slides demais, palavras demais

Winston conta que uma vez um cara pediu pra ele revisar os slides de um job talk. Ele disse: "Você tem slides demais e tem palavras demais." O cara perguntou como ele sabia. Resposta: porque sempre tem.

Props criam empatia espelhada

Os dramaturgos já sabem disso. Winston cita uma peça do Ibsen onde um forno barrigudo fica em cena a peça inteira — o fogo cresce, e você sabe que aquele manuscrito vai acabar queimado.

Exemplo em sala: ele conta do professor de física do MIT que, pra ensinar conservação de energia, encostava a cabeça numa parede, liberava uma bola de aço gigante numa corda e esperava ela voltar e beijar seu nariz de leve. Você nunca esquece depois disso.

📱 A regra que Winston sempre usa

Sem laptops. Sem celulares.

Não é mania de velho. É que temos um único processador de linguagem. Se ele está ocupado lendo e-mail, você está distraído — e pior, distrai quem está ao redor.

✓ Sucesso = comunicação > escrita > qualidade das ideias
✓ K + P > Talento. Conhecimento e prática vencem
✓ Não comece com piada. Comece com promessa de capacitação
✓ Repita sua ideia 3 vezes (cycling)
✓ Construa uma cerca: compare com o que a ideia não é
✓ Use pontuação verbal ("primeiro…, segundo…")
✓ Faça perguntas. Espere até 7 segundos pela resposta
✓ 11h da manhã é o melhor horário
✓ Sala bem iluminada. Mais da metade cheia
✓ Quadro > slides pra ensinar. Slides são condimento, não prato
✓ Props ativam neurônios-espelho — funcionam
✓ Sem laptops e celulares na plateia

🎧 Resumo de Live

Live original: 2h 29min  ·  Leitura deste resumo: 12 min

A "planilha inútil"

Rony, formado em engenharia de produção, passava dias em casa criando planilhas complexas pra planejar a próxima empresa. O pai dele viu a cena e deu o conselho que mudaria tudo:

Virou o mantra da Reserva: tirar a bunda da cadeira e ir pra rua.

O primeiro fracasso e o fim do dinheiro dos outros

Aos 16 anos, montou um site que crescia rápido com dinheiro de terceiros. Quando a bolha da internet estourou, ele quebrou.

Cinco caras com a mesma bermuda

Rony estava numa academia e notou cinco caras usando exatamente a mesma bermuda de uma marca carioca. A conclusão foi óbvia:

Com R$ 3.000 dele e R$ 3.000 do sócio Fernando, foram a uma fábrica e fizeram a primeira bermuda.

Por que não começaram com lojas próprias

Por medo de quebrar. "A gente descobriu que se começasse pelo varejo, a gente ia quebrar. Varejo no Brasil quebra no fluxo de caixa e no capital de giro."

Pós-venda: como intraempreendedores na nova estrutura, quintuplicaram a companhia — de R$ 400 milhões para quase R$ 2 bilhões em 4 anos.

Programa de sociedade: ao saírem, deixaram 29 sócios e sócias na operação, garantindo crescimento sem os fundadores.

Vendas e o Resto

No começo, o empreendedor faz tudo. O foco absoluto deve ser vender.

Pessoas e Processos

Com market fit validado e crescimento acelerando, o empreendedor não dá mais conta sozinho. Hora de contratar pessoas certas (alinhadas aos valores e complementares tecnicamente) e criar processos.

Gestor de Gestores (O Verdadeiro Dono)

O fundador precisa parar de trabalhar "ombro a ombro" na operação e se tornar um gestor de gestores.

❌ Ficar preso em planilhas em vez de vender — planejamento excessivo sem validação de mercado é fatal
❌ Depender de capital externo pra sobreviver — o negócio precisa gerar o próprio caixa
❌ Tentar abraçar o mundo sozinho na Fase 2 — não sistematizar processos sobrecarrega o fundador
❌ O "Muro de Berlim" entre empreendedores e executivos — líderes corporativos precisam ser intraempreendedores

❝ "Tem vez em que você acerta e outra vez em que você aprende."

❝ "Quem faz cem vendas descobre como ser melhor todos os dias."

❝ "Dentro de uma empresa, os bons líderes têm que descer na estrutura organizacional aprendendo, e subir fazendo."

❝ "Se o conselho é bom, o exemplo arrasta."

❝ "Varejo de moda é indubitavelmente o mercado mais difícil pra você empreender. Você tem que ser um generalista no conhecimento."

✓ Larga a planilha e vai pra rua vender
✓ O negócio tem que se sustentar com caixa próprio
✓ R$ 6 mil de investimento inicial → R$ 2 bi de faturamento
✓ 20 anos sem registrar 1 ano de prejuízo
✓ Fase 1: vendas e o resto
✓ Fase 2: pessoas e processos
✓ Fase 3: gestor de gestores
✓ Bons líderes descem aprendendo e sobem fazendo
✓ Saíram deixando 29 sócios na operação