📖 Glossário vivo (leia antes — volte sempre que precisar)
A Trilha 1 já fixou o vocabulário-base (modelo, prompt, agente, skill, harness). Aqui na Trilha 2 — Habilidades Humanas entram os termos NOVOS deste módulo. Fixe estes antes de seguir:
📚 Ousterhout e os dois modos
🧠 Imagine assim: um exército tem dois tipos de gente. O soldado aperta o gatilho na hora da batalha — ação imediata, no chão. O general fica no topo da colina decidindo onde atacar, como posicionar tudo pra ganhar a guerra. Programar tem esses dois modos exatamente iguais.
Antes de falar de IA, precisamos de uma régua. Matt Pocock pega ela emprestada de John Ousterhout, professor de Stanford e autor de "A Philosophy of Software Design". No livro, ele separa o trabalho de programar em dois modos bem diferentes: programação tática e programação estratégica. Não são "níveis de habilidade" — são jeitos de pensar sobre o que você está fazendo agora.
A diferença, na imagem do próprio Pocock: o tático é "ganhar a batalha" — o dia-a-dia de escrever sintaxe, achar bugs, fazer commits. O estratégico é "ganhar a guerra": é o general no topo pensando em como o codebase precisa ser e quais estratégias aumentam a velocidade no longo prazo. O porquê disso virou tema agora: a IA mudou radicalmente quem faz cada modo. Um erro comum é tratar os dois como a mesma coisa ("é tudo programar") — eles pedem cabeças diferentes.
Dois modos de pensar, não dois níveis. A IA mudou quem faz cada lado.
⚠️ Erro comum de iniciante
Achar que "saber programar" = "digitar código rápido". Esse é só o lado tático. Quem só treina o tático fica fácil de substituir — justamente o lado que a IA já faz melhor que você.
Em 1 frase: tático = ganhar a batalha (o código de hoje); estratégico = ganhar a guerra (o sistema do amanhã).
Indo mais fundo (opcional): por que Ousterhout, e não outro autor?
"A Philosophy of Software Design" é curto, prático e foi escrito muito antes do boom da IA — por isso ele isola tático × estratégico como princípios de design, não como moda. Pocock gosta de citá-lo justamente porque é um fundamento "que funciona há 30-40 anos" (a tese da Trilha 1): quando você ancora no fundamento certo, a chegada da IA só muda quem executa, não o que importa.
⌨️ Programação tática
🧠 Imagine assim: é o pedreiro assentando tijolo por tijolo. Trabalho real, necessário, visível — mas ele não decide onde a casa fica nem quantos quartos ela tem. Ele executa a parede que mandaram levantar.
A programação tática é o trabalho que você vê acontecendo: abrir o editor e escrever as linhas, lembrar onde vai o parêntese, rodar o programa, ver que quebrou, caçar o bug, corrigir, e salvar com um commit. É o "chão de fábrica" do software. Por décadas, foi aqui que a maioria dos programadores passava 80% do tempo — e era aqui que se media "quem programa bem".
É um trabalho honesto e indispensável: sem o tático, nada roda. Mas tem uma característica perigosa — ele é mecânico e padronizável. Quase toda tarefa tática já foi feita milhões de vezes por alguém: criar um endpoint, validar um formulário, escrever um loop. Por isso o porquê importa: tudo que é repetível e bem-definido é exatamente o tipo de coisa que máquinas aprendem a fazer. O erro comum é confundir "estou ocupado digitando" com "estou criando valor" — muita digitação pode esconder pouca decisão.
Recuperação rápida: qual destes é trabalho tático?
Em 1 frase: o tático é o "assentar tijolo" do software — necessário, mas repetível e fácil de automatizar.
🗺️ Programação estratégica
🧠 Imagine assim: o arquiteto da casa. Ele não assenta nenhum tijolo, mas decide onde fica a fundação, como os cômodos se conectam, por onde passa o encanamento. Uma decisão dele errada custa 1000 tijolos remendados depois.
A programação estratégica é o oposto do "está digitando". É pensar antes e em volta do código: como o codebase deve ser estruturado, quais interfaces conectam as partes, que decisões de hoje vão acelerar (ou travar) a equipe daqui a um ano. Nas palavras de Pocock, é "ganhar a guerra, não a batalha" — o trabalho do general no topo.
Para Ousterhout, o estratégico envolve desenhar as partes difíceis antes, escopar bem cada tarefa, pensar nas interfaces entre módulos, planejar testes e cenários, e projetar um codebase fácil de trabalhar. O porquê de isso ser raro: dá pra "entregar" sem fazer nada disso — basta empurrar código tático que funciona hoje. O preço vem depois, em forma de dívida técnica. O erro comum é adiar o estratégico "pra quando tiver tempo": ele nunca chega, e o codebase apodrece.
🔬 Exemplo resolvido: a mesma feature, dois modos
Tarefa: "adicionar pagamento por cartão". Veja a diferença entre só-tático e estratégico:
Só tático
Chama a API de pagamento direto na tela do carrinho, copia o código de validação de outro lugar, faz o commit. Funciona hoje. → Quando entrar Pix, boleto e assinatura, cada um vira outro remendo grudado na tela. Vira um labirinto.
Estratégico primeiro
Desenha uma interface "MeioDePagamento" com um contrato claro; cartão é a primeira implementação; escreve testes do contrato. → Pix e boleto entram só implementando a mesma interface. A IA executa cada um sozinha, seguindo o molde.
Em 1 frase: o estratégico é projetar o terreno pra que cada feature futura (sua ou da IA) seja fácil de encaixar.
🤖 Por que a IA dominou o tático
🧠 Imagine assim: a caixa registradora "comeu" a conta de cabeça do caixa. Ninguém mais é contratado por somar rápido. O valor migrou pra quem decide o preço, a vitrine, o que vender. A IA fez isso com o tático.
Aqui está a frase que dá nome ao módulo. Matt Pocock é direto: "AI has basically eaten tactical programming. It's gone." — a IA basicamente "comeu" a programação tática, ela acabou. Não no sentido de que o tático não existe mais, mas no sentido de que já não é onde está o seu valor: a IA faz o tático melhor e mais barato que você. Lembra do tópico 2? O tático é repetível e bem-definido — e é exatamente nisso que um modelo de linguagem brilha.
A consequência prática é forte: você passou a ter acesso a uma "frota infinita de programadores táticos" que trabalham 24h, não cansam e custam centavos. Mas — e aqui mora o ponto — uma frota só vale o quanto vale quem a comanda. O porquê de isso te empurrar pra cima: se o tático ficou barato e abundante, o gargalo virou o estratégico. O erro comum é continuar competindo no tático ("vou digitar mais rápido que a IA") — é uma corrida que você perde, contra alguém que não dorme.
⚠️ Erro comum
"Se a IA faz o tático, eu não preciso mais entender código." Errado: você ainda precisa ler e julgar o tático pra comandar a frota. O que muda é que parar no tático deixou de ser suficiente — não que ele deixou de importar.
Em 1 frase: a IA comeu o tático — então o seu valor migrou todo pro estratégico.
🧗 Subir de nível
🧠 Imagine assim: o melhor cozinheiro da cozinha vira chef. Ele continua sabendo cortar e fritar — mas agora seu valor está no cardápio, na brigada, no padrão de cada prato. Quem fica só na faca nunca abre restaurante.
Se o tático foi absorvido, a jogada é subir de nível: passar a operar no estratégico. Pocock é claro que "strategic programming não mudou com a IA" — os fundamentos de desenhar bem um sistema são os mesmos de sempre. O que mudou foi pra quem você delega o tático: antes você passava as tarefas mecânicas pra juniores e mid-levels; agora você delega pra IA. O porquê de isso ser libertador: você gasta menos tempo digitando e mais tempo decidindo — que é onde o resultado real se forma. O erro comum é "subir de nível" só no cartão de visita (virar "líder") sem nunca soltar o tático na prática; aí você vira um gargalo que revisa cada linha. Subir de verdade é confiar a execução e focar no design.
✓ Subir de nível
- • Desenhar interfaces e escopo antes de codar.
- • Delegar o tático à IA e revisar com critério.
- • Gastar o tempo livre pensando o sistema.
✗ Travar no tático
- • Competir com a IA na velocidade de digitar.
- • Reescrever na mão o que a IA já entregou.
- • Adiar o design "pra quando sobrar tempo".
Em 1 frase: o estratégico não mudou — só trocou o "júnior" pela IA; sua vez é virar quem dá a direção.
🎖️ O general no topo
🧠 Imagine assim: o general não dispara o canhão — ele decide onde o canhão aponta. Se ele descer pra atirar, ninguém comanda o exército. Seu lugar é no topo da colina, lendo o mapa inteiro.
Fechando o módulo: a metáfora do general no topo é o resumo de tudo. A IA é a sua tropa tática; você é o general estratégico. Para delegar bem essa tropa — o tema da Trilha 2 inteira — Pocock dá a lista do Ousterhout: desenhar as partes difíceis na frente, escopar muito bem as tarefas, pensar nas interfaces entre módulos, pensar em testes e cenários, e ter documentação suficiente pra apontar a IA pros lugares certos. Antes de "mandar a IA codar", rode o checklist abaixo — é o resumo prático deste módulo. Copie e cole quando for delegar uma tarefa:
Antes de mandar a IA codar, pense como GENERAL (estratégico): [ ] PARTES DIFÍCEIS — qual é o pedaço arriscado? Desenhei ele na frente? [ ] ESCOPO — a tarefa está nítida e fechada, ou está vaga demais? [ ] INTERFACES — como este módulo conversa com os outros? Defini o contrato? [ ] TESTES — quais cenários provam que ficou certo (inclusive os de borda)? [ ] DOCUMENTAÇÃO — apontei a IA pros arquivos/padrões certos do projeto? Se respondeu tudo, o tático (a IA) é só execução. Você ganhou a guerra.
Recuperação rápida: o que Pocock quer dizer com "a IA comeu o tático"?
Em 1 frase: seu lugar é o topo da colina — defina a guerra e deixe a tropa tática (a IA) ganhar as batalhas.
🧾 Resumo do Módulo
Próximo módulo:
2.2 — Suas skills são o teto: por que você é o multiplicador da IA, e como o sênior ganha 10x.