1. Introdução e Contexto

Esta apostila é baseada na palestra e workshop ministrados por Matt Pocock, professor e especialista em TypeScript, no evento de conferência documentado no vídeo de referência. O tema central é que, apesar de a IA representar um novo paradigma tecnológico, os fundamentos da engenharia de software que sempre funcionaram para humanos também funcionam de forma excelente ao trabalhar com IA.

1.1 A Tese Central

A ideia chave da palestra é:

• Todos acreditam que a IA é um paradigma completamente novo

• Esquecemos que os fundamentos da engenharia de software continuam essenciais

• Essas práticas clássicas funcionam muito bem quando aplicadas a LLMs

Citação do autor

"Quando falamos sobre IA como um novo paradigma, esquecemos que os fundamentos da engenharia de software - as coisas que são cruciais para trabalhar com humanos - também funcionam muito bem com IA."

1.2 Público e Contexto

A palestra foi apresentada para um grupo de desenvolvedores com diferentes níveis de experiência com IA, com perguntas e demonstrações ao vivo. O workshop tem duração de aproximadamente 2 horas e inclui exercícios práticos.

2. Restrições Fundamentais dos LLMs

Antes de entrar nas técnicas práticas, é essencial compreender as limitações técnicas dos modelos de linguagem grandes (LLMs). O autor identifica duas restrições principais que moldam toda a abordagem de desenvolvimento com IA.

2.1 As Duas Restrições Principais

Restrição	Descrição
Zona Inteligente / Zona Burra	LLMs degradam em qualidade conforme a janela de contexto cresce
O Efeito Memento	LLMs não possuem memória entre sessões; resetam ao estado inicial

Compreender essas duas restrições é o ponto de partida para toda a metodologia apresentada neste workshop.

3. O Problema do Contexto: Zona Inteligente e Zona Burra

Este conceito, atribuído a Dex Hardy da empresa Human Layer, é fundamental para trabalhar com LLMs de forma eficiente.

3.1 Como Funciona a Atenção nos LLMs

Cada vez que você adiciona um token a um LLM, o número de relações de atenção cresce de forma quadrática - semelhante ao número de jogos em uma liga de futebol conforme novas equipes são adicionadas. Isso ocorre porque há relações de atenção de cada token para todos os outros, envolvendo posição e significado individual de cada token.

3.2 Definição das Zonas

Zona	Característica
Zona Inteligente	Início da conversa, contexto limpo, LLM trabalha com máxima eficiência
Zona Burra	Contexto sobrecarregado (~100K tokens), LLM começa a tomar decisões ruins

Marcador prático

O autor usa ~100K tokens como referência para o início da zona burra, independentemente do tamanho total da janela de contexto (1 milhão ou 200K). Sempre monitore o contador de tokens.

3.3 Estratégias para Trabalhar na Zona Inteligente

• Dimensione as tarefas para caber dentro da zona inteligente

• Não deixe a IA 'morder mais do que pode mastigar'

• Mantenha o prompt de sistema (system prompt) pequeno e enxuto

• Evite acumular sedimentos desnecessários no contexto

Referência clássica

O autor cita Martin Fowler (Refactoring) e The Pragmatic Programmer - livros que já ensinavam: 'Não assuma mais do que você pode executar. Mantenha suas tarefas pequenas para que você, como desenvolvedor humano, não entre em pânico e caia na zona burra.'

3.4 Fases de uma Sessão LLM

Toda sessão com um LLM passa pelas mesmas fases:

• Prompt de sistema (system prompt) - sempre presente no contexto

• Fase exploratória - o agente explora o código-base

• Implementação - escrita efetiva do código

• Testes - loops de feedback e validação

3.5 Compactação vs. Limpar o Contexto

Quando você se aproxima do limite, existem duas opções:

• Compactação (Compacting): resume toda a conversa em um histórico menor e continua

• Limpar (Clear): apaga tudo e volta apenas ao prompt de sistema

O autor prefere claramente a segunda opção (limpar), pois:

◦ O estado inicial é sempre o mesmo - previsível e consistente

◦ Compactações acumulam 'sedimentos' que degradam a qualidade

◦ Reiniciar permite trabalhar sempre na zona inteligente

4. Os LLMs como o Personagem de Memento

A segunda restrição fundamental é que os LLMs são como o protagonista do filme Memento: eles esquecem tudo e voltam ao estado base a cada nova sessão. Não há persistência de memória entre conversas.

Isso significa que toda estratégia de desenvolvimento com IA precisa considerar:

• Não confiar na memória do LLM entre sessões

• Criar documentos e artefatos externos que persistam o contexto

• Projetar fluxos que funcionem bem com contexto recém-inicializado

• Enxergar o reinício como uma vantagem (sempre começa no melhor estado)

Insight-chave

Em vez de tentar compensar o esquecimento do LLM, o autor abraça essa característica e projeta seu fluxo de trabalho para tirar vantagem dela: trabalhar sempre com contexto limpo significa trabalhar sempre na zona inteligente.

5. O Fluxo de Desenvolvimento com IA

Com base nas restrições entendidas, o autor apresenta um fluxo de desenvolvimento estruturado que maximiza a eficiência do LLM enquanto mantém o controle humano nos pontos críticos.

5.1 Visão Geral do Fluxo

Fase	Atividade
1. Alinhamento	Sessão de interrogatório (Grill Me) - HUMANO no loop
2. Documentação	Criação do PRD (Product Requirements Document) - HUMANO revisa
3. Planejamento	Criação do Kanban Board com issues paralelas - HUMANO valida
4. Implementação	Loop AFK com agentes (Ralph Loop) - IA trabalha sem supervisão
5. QA e Review	Testes, code review, iterações - HUMANO impõe padrões e gosto

5.2 Tarefas Humanas vs. Tarefas AFK

O autor distingue claramente dois tipos de tarefas:

Tipo	Descrição
Human-in-the-loop	Requerem presença humana: planejamento, alinhamento, QA
AFK (Away From Keyboard)	Podem ser delegadas totalmente à IA: implementação

Analogia: turno do dia e da noite

O planejamento é o turno do dia - o humano organiza tudo. A implementação é o turno da noite - a IA trabalha AFK enquanto o humano descansa ou faz outras coisas.

5.3 Crítica ao Movimento 'Specs to Code'

O autor critica fortemente a abordagem de 'especificações para código' que é popular atualmente:

• Consiste em escrever especificações detalhadas e simplesmente transformá-las em código via IA

• Se algo der errado, você edita a especificação, não o código

• É essencialmente 'vibe coding' com outro nome

• O autor testou e afirma que simplesmente não funciona

O motivo pelo qual falha:

◦ Você precisa manter controle sobre o código

◦ Você precisa entender o que está dentro do código

◦ Você precisa moldar o código porque ele é o seu campo de batalha

6. Fase 1 - O Interrogatório (Grill Me Skill)

A primeira fase do fluxo é o que o autor chama de 'Grill Me' (me interrogue). Esta é a etapa de alinhamento entre o desenvolvedor e o LLM antes de qualquer escrita de código.

6.1 O Problema de Alinhamento

O principal problema ao trabalhar com IA no desenvolvimento de software é o misalignment - quando o desenvolvedor e o LLM têm entendimentos diferentes sobre o que está sendo construído. O 'Grill Me' resolve isso.

6.2 Como Funciona

O skill 'Grill Me' é uma instrução pequena e concisa que instrui o LLM a:

• Fazer perguntas agressivas e diretas sobre a ideia sendo desenvolvida

• Continuar questionando até ter um entendimento completo do problema

• Explorar edge cases, decisões técnicas e escopo

• Criar um 'conceito de design compartilhado' entre humano e IA

Resultado do Grill Me

Após uma sessão de interrogatório, o autor usa ~25K tokens. Todo esse conteúdo é 'ouro' - um alinhamento profundo sobre o que será construído. Esse contexto é então destilado em documentos permanentes.

6.3 Por Que Não Usar Ferramentas como Taskmaster ou Spec Kit?

O autor foi questionado sobre frameworks alternativos. Sua posição:

• Com tantas ferramentas surgindo e mudando, você precisa ser dono do seu planejamento

• Estudantes que adotam stacks de terceiros sem entendê-las ficam presos quando algo dá errado

• Controle total da sua stack = capacidade de corrigir problemas

6.4 Aplicação em Equipes

Para equipes maiores, o Grill Me pode ser usado em par ou em grupo:

• Pair programming com IA: um terceiro personagem que questiona incansavelmente

• Mob programming com IA: múltiplos humanos e a IA na mesma sessão

• As decisões cruciais precisam de humanos; a IA facilita o processo

7. Fase 2 - O Documento de Requisitos (PRD)

Após o interrogatório, o próximo passo é transformar o alinhamento alcançado em um documento permanente: o Product Requirements Document (PRD).

7.1 A Função do PRD

O PRD serve como o 'documento de destino' - descreve para onde estamos indo. Diferente dos planos de implementação, o PRD define o estado final desejado.

7.2 Estrutura Recomendada do PRD

Seção do PRD	Conteúdo
Declaração do Problema	Qual problema o usuário enfrenta
Solução Proposta	Como resolver o problema
User Stories	Lista de histórias de usuário (~15-20 itens)
Decisões de Implementação	Escolhas técnicas feitas
Decisões de Testes	Estratégia de testes
Módulos Propostos	Quais partes do código serão modificadas
Fora do Escopo	O que NÃO será feito nesta iteração

7.3 Módulos no PRD - O Código Sempre em Mente

Um diferencial importante da abordagem: ao criar o PRD, já se pensa nos módulos de código que serão afetados. Isso garante que o processo nunca ignore o código-base real.

• Identifica os módulos que serão criados ou modificados

• Define as interfaces que cada módulo vai expor

• Classifica dependências: locais, substituíveis, banco de dados de teste

7.4 Deve-se Revisar o PRD?

Surpreendentemente, o autor afirma que geralmente NÃO lê o PRD gerado:

• LLMs são excelentes em sumarização - isso já está garantido

• Após a sessão de interrogatório, o alinhamento já existe

• Revisar seria apenas verificar a capacidade de sumarização do LLM

7.5 Doc Rot - Cuidado com Documentação Antiga

O autor alerta sobre um perigo chamado 'doc rot': documentação antiga que permanece no repositório e contamina o contexto do agente com informações desatualizadas.

Boa prática

Após a implementação ser concluída, feche ou arquive o PRD. Se usar GitHub Issues, marque como fechado. Não deixe documentação de especificação desatualizada flutuando no repositório, pois o LLM pode encontrá-la e usá-la como verdade.

8. Fase 3 - O Kanban Board e Paralelismo

Com o PRD definido, o próximo passo é transformar os requisitos em issues (tickets) independentes que podem ser trabalhados em paralelo por múltiplos agentes.

8.1 De Plano Sequencial para Grafo Acíclico Dirigido

A maioria dos desenvolvedores usa planos sequenciais em fases (fase 1, fase 2, fase 3). O autor argumenta que isso limita o paralelismo:

• Plano sequencial: apenas um agente pode trabalhar por vez

• Kanban com dependências: múltiplos agentes podem trabalhar em paralelo nas tarefas sem bloqueio

A estrutura ideal é um Directed Acyclic Graph (DAG) - um grafo acíclico dirigido onde as dependências entre tarefas são explícitas e apenas o necessário é sequencial.

8.2 Vertical Slices vs. Horizontal Slices

Um conceito central na criação dos issues é preferir fatias verticais:

Tipo de Slice	Descrição
Horizontal (BAD)	Implementa uma camada por vez (ex: só o serviço, só o banco)
Vertical (GOOD)	Implementa uma funcionalidade completa de ponta a ponta

Exemplo de vertical slice

Em vez de 'criar o serviço de gamificação' (horizontal), prefira 'mostrar pontos ganhos por conclusão de aula no dashboard' - isso toca no schema, no serviço e no frontend simultaneamente, resultando em algo visualmente testável.

8.3 Características dos Issues Ideais

• Independentes - podem ser pegos por qualquer agente

• Com dependências explícitas mapeadas

• Com critérios claros de conclusão

• Em fatias verticais (mostram resultado visível ao final)

• Organizados como um grafo, não uma lista linear

8.4 Ferramentas para o Kanban

O autor usa GitHub Issues como ferramenta principal, mas menciona que arquivos locais em Markdown também funcionam para fins didáticos. Issues fechadas no GitHub ficam acessíveis mas com indicador visual de 'feito'.

9. Fase 4 - Implementação AFK (Loop Ralph)

Com o Kanban preparado, chega a fase onde o humano sai do loop e os agentes trabalham autonomamente. O autor chama isso de 'Ralph Loop'.

9.1 O Conceito Ralph

Baseado na ideia de 'Ralph Wiggum' como prática de software, o Ralph Loop funciona assim:

• Define-se um destino (PRD + issues)

• O agente faz uma pequena mudança de cada vez que o aproxima do destino

• O loop continua até que todas as tarefas estejam completas

Analogia com o loop

O autor compara ao raciocínio: se você tem fase 1, fase 2, fase 3, fase N... por que não ter apenas fase N? Um loop que continua até a conclusão.

9.2 Estrutura Técnica do Loop

O script (once.sh) que executa o loop faz o seguinte:

• Coleta todas as issues do backlog em arquivos Markdown

• Captura os últimos 5 commits do repositório

• Passa tudo para o Claude Code com modo de permissão automática

• O agente escolhe a próxima tarefa, implementa, e registra o resultado

9.3 Prioridades do Agente no Loop

O prompt do loop AFK define prioridades:

• 1. Correções de bugs críticos

• 2. Infraestrutura de desenvolvimento

• 3. Tracer bullets (funcionalidades de ponta a ponta mínimas)

• 4. Quick wins e refatorações

9.4 Modo Sequencial vs. Paralelo

O autor recomenda começar com o modo sequencial (um agente de cada vez) para ganhar familiaridade antes de partir para a paralelização.

Paralelização avançada

Com múltiplos agentes em paralelo, cada um trabalha em uma branch separada dentro de um sandbox Docker. Um agente 'planner' escolhe as tarefas sem bloqueio mútuo, agentes 'implementers' executam em paralelo, e um agente 'merger' consolida os resultados, resolvendo conflitos de tipos e testes.

10. Test-Driven Development (TDD) com IA

O TDD é apresentado como absolutamente essencial para obter o máximo dos agentes de IA. O autor afirma ter moldado toda a sua técnica em torno de fazer o TDD funcionar bem.

10.1 Red-Green-Refactor com IA

O ciclo clássico do TDD funciona assim:

• Red: Escreva um teste que falha (a funcionalidade ainda não existe)

• Green: Escreva o código mínimo para fazer o teste passar

• Refactor: Melhore o código mantendo os testes passando

10.2 Por Que a IA Escreve Testes Ruins Sem TDD

Sem TDD, a IA tende a 'trapacear':

• Escreve toda a implementação primeiro

• Depois escreve os testes para a implementação que já existe

• Os testes ficam acoplados à implementação, não à especificação

Com TDD, esse problema é muito mais difícil de ocorrer porque:

◦ O teste é escrito ANTES da implementação

◦ O código é instrumentado antes de ser escrito

◦ A ordem natural força testes baseados em comportamento

10.3 Loops de Feedback - O Teto da Qualidade

Os loops de feedback (rodar testes, verificar tipos) são essenciais para qualquer output razoável da IA:

Loop de Feedback	Propósito
npm run test	Verificar que a lógica de negócio funciona
npm run type-check	Garantir correção de tipos (TypeScript)
Feedback visual (QA)	Verificar que o resultado é visível e correto

Insight fundamental

Se você está recebendo outputs ruins do agente, frequentemente a solução é melhorar a qualidade dos seus loops de feedback. O teto da qualidade do output é determinado pela qualidade dos seus mecanismos de verificação.

11. Arquitetura de Código: Módulos Profundos vs. Rasos

Baseado no livro 'The Philosophy of Software Design' de John Ousterhout, o autor apresenta um conceito crucial para código que funciona bem com IA.

11.1 Módulos Rasos (Shallow Modules) - Evitar

Módulos rasos são caracterizados por:

• Muitos arquivos pequenos com poucas responsabilidades

• Interfaces complexas expondo muitas funções

• Dependências cruzadas difíceis de rastrear

Problemas com módulos rasos para IA:

◦ A IA precisa navegar manualmente por todo o grafo de dependências

◦ Difícil definir fronteiras de teste

◦ Mocks excessivos tornam os testes frágeis e sem sentido

11.2 Módulos Profundos (Deep Modules) - Ideal

Módulos profundos têm:

• Interface pequena e simples (poucos pontos de entrada)

• Muita funcionalidade encapsulada internamente

• Fronteiras de teste claras e naturais

Vantagens para IA:

◦ A IA entende facilmente o que o módulo faz pela sua interface

◦ Fácil envolver com um único teste abrangente

◦ Comportamento testável do exterior sem necessidade de mocks complexos

Comportamento natural da IA

Sem orientação, a IA naturalmente produz código com módulos rasos. É preciso orientá-la ativamente para criar módulos profundos, tanto no PRD (definindo as interfaces) quanto durante a implementação.

11.3 A Estratégia dos 'Gray Boxes'

O autor propõe uma abordagem mental para manter domínio sobre o código:

• Projete as interfaces dos módulos você mesmo

• Delegue a implementação interna para a IA

• Você não precisa saber todos os detalhes internos

• Você precisa saber o que cada módulo faz e como ele se comporta

Resultado: você mantém o senso do código-base enquanto preserva sua sanidade mental diante do volume de código gerado por IA.

11.4 A Habilidade 'Improve Codebase Architecture'

O autor demonstra uma skill que escaneia o código-base em busca de:

• Módulos que poderiam ser aprofundados

• Grupos de módulos relacionados que poderiam ser testados como uma unidade

• Lacunas de cobertura de testes

• Oportunidades de simplificação de interfaces

12. QA e Code Review com IA

A fase de QA é onde o desenvolvedor humano impõe seus padrões, gosto e julgamento ao código gerado pela IA.

12.1 A Importância do QA Humano

O autor observa que equipes que tentam automatizar tudo - incluindo planejamento, QA, pesquisa e protótipos - acabam com aplicações que:

• Carecem de gosto e qualidade

• Não funcionam como esperado

• São 'slop' (conteúdo de baixa qualidade sem julgamento)

O toque humano é essencial. QA não é apenas sobre bugs - é sobre impor os padrões e a visão do desenvolvedor.

12.2 Code Review na Zona Inteligente

Um insight técnico importante: fazer code review após uma longa implementação significa revisar na zona burra. A solução:

• Limpe o contexto antes de fazer code review

• Revise com o contexto em estado inicial (zona inteligente)

• O revisor terá mais capacidade de atenção e identificará mais problemas

12.3 Estratégia de Review

Processo recomendado pelo autor:

• 1. Revisar primeiro os testes - verificar se estão testando coisas razoáveis

• 2. Revisar o código - verificar se não está fazendo nada louco

• 3. Fazer QA manual - testar visualmente o resultado

• 4. Criar novas issues para problemas encontrados - alimentando o Kanban

Code Review pelo Agente

Para review automático: use um agente revisor separado com o contexto limpo, passando tanto o código quanto os padrões de codificação (push). O implementador pode consultar os padrões por pull quando necessário.

13. Padrões Push e Pull para Agentes

Para garantir que os agentes sigam os padrões de codificação e estilos do projeto, o autor distingue dois mecanismos complementares.

13.1 Push - Instrução Proativa

No padrão Push, você injeta informações diretamente no contexto do agente:

• Colocar regras no Claude.md ou em arquivos de configuração

• O agente sempre recebe essas instruções, independente da tarefa

• Ideal para padrões críticos que nunca devem ser ignorados

13.2 Pull - Informação sob Demanda

No padrão Pull, você disponibiliza informações que o agente pode consultar quando necessário:

• Skills (habilidades) armazenadas no repositório com cabeçalho descritivo

• O agente lê 'OK, agente, você pode puxar este arquivo quando precisar'

• Reduz o tamanho do contexto inicial

• Ideal para conhecimento especializado usado em contextos específicos

Mecanismo	Quando Usar
Push	Padrões críticos, regras de segurança, convenções sempre aplicáveis
Pull (Skills)	Conhecimento especializado, padrões de contexto específico

13.3 Aplicação em Code Review

Para code review automatizado, a estratégia é:

• PUSH os padrões de codificação para o agente revisor

• PULL os padrões para o agente implementador (ele pode consultar se tiver dúvida)

• O revisor precisa dos padrões ativamente; o implementador os consulta ocasionalmente

14. Sandcastle: Automação Avançada

Para demonstrar a paralelização completa, o autor apresenta o Sandcastle, uma biblioteca TypeScript que ele desenvolveu para orquestrar agentes em paralelo.

14.1 O Problema que Sandcastle Resolve

O autor não estava satisfeito com as opções existentes para executar agentes 'AFK'. Sandcastle oferece:

• Função run() que cria uma work tree em uma branch Git

• Sandbox em container Docker para cada agente

• Execução de prompts dentro desse ambiente isolado

• Paralelização simplificada de múltiplos agentes

14.2 Fluxo do Sandcastle

O processo completo:

• Um agente Planner analisa o backlog e escolhe tasks sem bloqueios mútuos

• Para cada issue, cria um sandbox e executa um agente Implementer

• Se commits foram criados, um agente Reviewer faz code review

• Um agente Merger consolida as branches, resolvendo conflitos de tipos e testes

14.3 Modelo de IA por Função

O autor usa modelos diferentes por tipo de tarefa:

Função	Modelo
Implementação	Claude Sonnet (rápido e eficiente)
Code Review	Claude Opus (maior capacidade de análise crítica)

Repositório open source

O autor disponibiliza o Sandcastle publicamente. Quem quiser aprofundar a paralelização de agentes pode consultar o código-fonte para aprender mais.

15. Princípios e Boas Práticas - Resumo Final

O autor encerra com uma síntese dos principais aprendizados. Esta seção consolida todos os conceitos em princípios acionáveis.

15.1 Os 10 Princípios Fundamentais

• 1. Conheça a Zona Inteligente

Monitore o contador de tokens em toda sessão. Nunca deixe o contexto crescer ao ponto de entrar na zona burra. Limpe o contexto regularmente ao invés de compactar.

• 2. Abrace o Esquecimento da IA

Projete seu fluxo para funcionar com contexto sempre limpo. Isso é uma vantagem, não uma limitação: você sempre começa no melhor estado possível.

• 3. Alinhe Antes de Implementar

Nunca delegue código sem antes executar uma sessão de interrogatório (Grill Me). O custo do realinhamento depois é sempre maior do que o custo do alinhamento antes.

• 4. Mantenha o Código em Mente

Nem durante o planejamento você pode ignorar o código. Pense em módulos, interfaces e arquitetura desde o primeiro momento.

• 5. Prefira Vertical Slices

Cada issue deve resultar em algo visível e testável de ponta a ponta. Evite 'camadas de bolo' (horizontais) que só mostram resultado depois de muitas implementações.

• 6. TDD é Inegociável

A IA sem TDD tende a escrever testes ruins ou a trapacear. Com TDD, a ordem natural força melhores práticas e gera código que a IA pode verificar autonomamente.

• 7. Melhore Seus Loops de Feedback

A qualidade do seu código gerado por IA é limitada pela qualidade dos seus mecanismos de verificação. Invista em testes bons, type checking e verificações automáticas.

• 8. Módulos Profundos, Não Rasos

Oriente a IA a criar módulos com interfaces pequenas e muita funcionalidade interna. Projete as interfaces você mesmo; delegue as implementações.

• 9. QA é Onde Você Impõe Seu Gosto

Não tente automatizar tudo. A fase de QA é onde o julgamento humano, a experiência e o senso estético são aplicados. Sem isso, o resultado é 'slop'.

• 10. Leia os Livros Clássicos

A recomendação final do autor: compre e leia os livros clássicos de engenharia de software (Martin Fowler - Refactoring, The Pragmatic Programmer, A Philosophy of Software Design). Eles codificam práticas que funcionam igualmente bem com humanos e com IA.

15.2 O Fluxo Completo em uma Visão

Etapa	Responsável
1. Ideia inicial	Humano
2. Grill Me (alinhamento)	Humano + IA (interativo)
3. PRD (documento de destino)	IA gera, Humano valida
4. Kanban (issues paralelas)	IA gera, Humano valida
5. Implementação (Loop AFK)	IA trabalha autonomamente
6. QA + Code Review	Humano + IA (revisão)
7. Iteração (novas issues)	Humano cria, ciclo repete

Reflexão final do autor

Este não é um compilador de especificações para código. Não é uma IA que simplesmente cospe código. É um processo intencional onde nos preocupamos com os módulos e com a forma do código-base. Usamos o interrogatório para garantir o máximo de alinhamento. Convertemos isso em issues paralelizáveis. Implementamos e fazemos QA e code review rigorosos, continuando a iterar.

Referências e Recursos

Livros Recomendados

• Refactoring - Martin Fowler

• The Pragmatic Programmer - David Thomas e Andrew Hunt

• A Philosophy of Software Design - John Ousterhout

Conceitos e Pessoas Mencionados

• Dex Hardy (Human Layer) - conceito de Zona Inteligente / Zona Burra

• Ralph Wiggum Loop - iteração contínua orientada a destino

• John Ousterhout - módulos profundos vs. rasos

Ferramentas e Recursos

• Claude Code - ferramenta principal usada no workshop

• Sandcastle - biblioteca TypeScript para paralelização de agentes (Matt Pocock)

• AI Hero - site do autor com artigos e dicas adicionais

• GitHub Issues / Kanban local - gestão de backlog para agentes