Quase ninguém entrega muito código com agentes de IA olhando para a tela. Theo Browne, criador do T3 Code, passou a mergear mais de 50 PRs por semana justamente quando parou de acompanhar as threads em tempo real e passou a investir em infraestrutura de verificação, não em prompts melhores.
Como agentes de IA mudaram a rotina de um dev que virou CEO
Agentes de IA bem configurados devolvem tempo de codificação a quem já não tem tempo livre. Theo Browne, criador do canal t3.gg e do T3 Code, descreveu em setembro de 2026 como saiu de uma ou três entregas semanais para 52 PRs em uma única semana, em agosto daquele ano, durante uma viagem à Defcon.
O salto não veio de prompts mais criativos. Veio de mover a execução para uma máquina Linux remota, aceitar threads paralelas e construir mecanismos que reduzem o risco de merge. Browne resume a filosofia em uma frase: você precisa de rede de segurança, não de trilhos.
O contexto importa para calibrar a expectativa. Ele administra empresas, grava vídeos e responde e-mails, então o tempo de código encolheu. O fluxo que ele apresenta é uma resposta a essa restrição, não uma receita universal de produtividade.
Passo a passo: como rodar vários agentes de IA em paralelo
Rodar vários agentes de IA em paralelo exige tirar a execução do seu notebook. Browne descreve um ciclo simples: abrir uma thread nova por atalho, colar o pedido e escolher qual máquina executa o trabalho, no caso dele um servidor Linux em outro cômodo da casa.
A sequência que ele repete é curta e vale como checklist:
- Abra uma thread nova por atalho, sem reaproveitar a anterior.
- Cole o pedido com objetivo, restrições e o que você já sabe do problema.
- Escolha a máquina remota que vai rodar a mudança, com worktree isolado.
- Feche a thread e volte só quando ela terminar.
O ponto contraintuitivo é o quarto passo. Browne afirma que acompanhar a thread não a faz terminar mais rápido e que, em quase todos os casos, você não vai interromper nada que já não pudesse esperar. Ele chama isso de etapa mais importante para quem quer entregar muito.
O motivo de preferir Linux é prático. Ele relata usar 5% ou menos da CPU com várias threads ativas em máquinas de 16 a 32 núcleos, incluindo um servidor de cerca de 600 dólares. Em macOS, ele diz tratar o computador como espaço para uma ou duas tarefas por vez.
Como escrever um prompt para agentes de IA que respeita suas prioridades
Um prompt eficaz para agentes de IA entrega contexto, prioridade e espaço para discordância. Browne usa prompts longos de propósito, em vez de comandos curtos, porque o agente precisa saber o que é inegociável e o que é apenas preferência.
Ele separa o texto em camadas: quantos usuários são afetados, o que ele quer que seja feito, até onde vai o seu conhecimento e o que ainda não entende. Ao dizer que não sabe como o comportamento é disparado, ele garante que a resposta explique o mecanismo, não apenas o resultado.
A frase que ele marca como linha sem compromisso é a que define simplicidade de implementação e clareza para o usuário. O “na minha opinião” que vem depois existe justamente para abrir a porta a um contra-argumento quando o caminho pedido for inviável.
Há um detalhe de custo que muda o cálculo. Browne prefere gastar tokens em auditorias do que descobrir um erro depois de montar um ambiente de teste, e classifica esse gasto como mais barato do que perder a motivação no meio da tarefa.
Auditoria de PR: onde uma segunda opinião automática ajuda
Auditoria de PR com um segundo modelo reduz o risco de você testar algo quebrado. Browne cola o link do pull request e pede uma análise de falhas, riscos para usuários e comparação com projetos que já resolvem o mesmo problema.
No caso que ele mostra, a auditoria apontou riscos concretos: chamadas de API frequentes demais, dados pouco confiáveis em painel e ausência de tratamento para respostas 429. Ele conta que o próprio modelo encontrou relatos de usuários que ficaram mais de 30 minutos sem conseguir consultar limites de uso.
O pedido inclui sempre o que importa para quem decide. Ele pergunta quais PRs estão prontos para merge, quais devem ser fechados e quais precisam de outra passada, com prioridade para o que é mais fácil de resolver. Isso transforma um relatório longo em uma lista de ações.
A lição prática é usar o modelo para descobrir o que testar. Browne deixa claro que não confia na auditoria como aprovação final; ele confia nela para saber onde vale gastar tempo de verificação manual.
Threads, snooze e a lista de trabalho que não vira cemitério
Uma lista de threads paralelas só funciona se cada item tiver um dono e um ciclo de vida claro. Browne trata a barra lateral do T3 Code como caixa de entrada: se a thread está ali, é porque ainda há trabalho a fazer nela.
Ele descreve três mecânicas que mantêm a lista enxuta. Ao mergear o PR vinculado, a thread sai da barra lateral. O que precisa voltar depois recebe snooze, com retorno marcado para algumas horas ou dias. E dá para fixar threads longas, como a do aplicativo em Swift, que ele mantém aberta porque depende da autorização de outra pessoa.
Ele também mostra como vincular manualmente um PR a uma thread quando o PR nasceu fora dela, o que faz a thread fechar sozinha quando o merge acontecer. É uma solução simples para um problema recorrente em fluxos com muitos agentes.
O efeito colateral é importante: cada thread precisa de um resumo do que está pendente. Sem isso, a lista deixa de ser caixa de entrada e passa a ser histórico morto.
Skill de babá: como automatizar o ciclo de revisão do PR
Uma skill de babá faz o agente acompanhar comentários automáticos e corrigir o próprio PR. Browne descreve uma skill de cerca de um parágrafo e meio que instrui o agente a observar o pull request, avaliar cada comentário de revisor automático e aplicar as mudanças válidas.
O ciclo que ele mostra é curto e mensurável. O agente recebeu 12 comentários na primeira passada, tratou todos, recebeu quatro, tratou, recebeu um, tratou, e chegou à aprovação dos bots de revisão sem intervenção humana.
Esse padrão só funciona quando existe revisão automática no repositório. Sem um bot que comente de forma consistente, a skill não tem sinal para consumir e o agente fica sem critério de conclusão.
Browne trata o resultado como encerramento do assunto. Quando o PR sai do radar dele, a thread correspondente também pode ser arquivada, o que devolve atenção para o próximo item.
Como testar mudanças remotamente: web, iOS e desktop
Testar uma mudança antes do merge é o que separa confiança de esperança, e cada plataforma exige um caminho diferente. Browne descreve três soluções construídas para validar mudanças sem estar na mesma máquina em que o agente trabalha.
No navegador, ele usa um comando interno que compartilha o servidor de desenvolvimento via Tailscale, gerando uma URL com código de pareamento. Ele relata que, em uma conexão de hotel de 10 megabits por segundo, carregar o servidor de desenvolvimento levava de 20 a 30 minutos antes de ele refazer o empacotamento.
No iOS, ele cita o Squim, uma ferramenta que compila o aplicativo em um Mac remoto e devolve um link instalável pelo navegador do celular. A limitação que ele aponta é clara: builds assim não recebem assinatura completa, então compartilhamento e AirDrop ficam restritos.
No desktop, ele automatizou um rótulo que dispara a compilação de um preview para macOS, com DMG disponível na própria thread. Depois de ajustar o processo de assinatura, o tempo total de build caiu cerca de um minuto e meio, segundo o próprio relato; o número exibido na tela dizia respeito à quantidade de chamadas de assinatura, não à build inteira.
Comparando as três plataformas, o trade-off fica evidente:
| Plataforma | Como validar | Principal limitação |
|---|---|---|
| Navegador | Servidor de desenvolvimento compartilhado via Tailscale | Depende da qualidade da rede |
| iOS | Build remota com link instalável | Sem assinatura completa, restringe compartilhamento |
| Desktop | Preview DMG disparado por rótulo | Exige pipeline de build configurado |
Nightly build e rede de segurança: como derrubar o medo do merge
Rede de segurança é o que permite mergear sem revisar cada linha de código. Browne descreve uma build nightly do T3 Code publicada a cada três horas, com alguns milhares de usuários dedicados que reportam problemas rapidamente.
O argumento dele é direto: se algo quebra, a falha aparece antes de atingir a base estável. Ele afirma que os releases estáveis praticamente não têm regressões reais justamente porque a nightly concentra a exposição. O contraponto honesto é que usuários de nightly aceitam quebras e remoções.
Há alternativas que ele menciona sem medir: lançamento gradual para 1% dos usuários com rollback rápido e equipe formal de QA. A escolha depende do tamanho da base e da tolerância a falhas, não de uma receita única.
O detalhe que fecha o raciocínio é o teste automatizado. Browne diz que o time mergeia mais testes do que funcionalidades hoje, o que sustenta a nightly como filtro e não como aposta.
O que dá para aplicar hoje com Crazystack Typescript
A parte transferível desse fluxo cabe em qualquer projeto, inclusive em uma stack como Crazystack Typescript. Comece reduzindo o atrito antes do PR: deixe o ambiente de teste a um comando de distância e garanta que qualquer pessoa consiga subir a aplicação sem ajuda.
Depois, separe execução de acompanhamento. Agentes de IA rodam melhor em máquina dedicada, com worktree isolado e recursos suficientes. Se você estuda esse tipo de organização em comunidade, cursos como o Bootcamp do Dev Doido e conteúdos do Gustavo Dev Doido cobrem a base de stack que sustenta esse tipo de pipeline.
Por fim, trate cada relatório de auditoria como fila de tarefas. Um fluxo com threads paralelas só escala quando cada thread tem critério claro de conclusão e um caminho conhecido de verificação.
A referência citada por Browne para infraestrutura de agentes que acessam a web é a Browserbase, patrocinadora do vídeo. Ele afirma que mais de 80% da web não pode ser acessada por requisições simples, número apresentado pela própria empresa, não por medição independente.
FAQ sobre agentes de IA no fluxo de desenvolvimento
- Quantos agentes de IA dá para rodar em paralelo com segurança? Browne relata ter rodado mais de 40 agentes ao mesmo tempo em uma máquina Linux de 32 núcleos, com uso de CPU abaixo de 10% em cargas leves. O limite prático aparece quando as tarefas exigem compilações pesadas que consomem toda a memória.
- Preciso de um servidor dedicado para usar agentes de IA? Não é obrigatório, mas ajuda. Browne menciona uma máquina de 16 threads comprada por cerca de 600 dólares que também deu conta do trabalho. O ganho vem de manter a execução fora do computador que você usa para outras tarefas.
- Qual a diferença entre rede de segurança e trilhos no fluxo com agentes? Rede de segurança é detectar e corrigir falhas rápido, com nightly e testes automatizados. Trilhos seriam restrições que impedem a mudança de existir. Browne defende a primeira abordagem porque ela libera o merge sem eliminar a verificação.
- Como saber se um PR gerado por agente está pronto para merge? Use auditoria automática como filtro inicial, não como aprovação. Browne pede ao modelo que liste riscos, compare com projetos semelhantes e aponte o que precisa mudar antes do merge, e depois testa a mudança em ambiente real.
- Vale a pena gastar tokens em auditoria em vez de simplesmente testar? Browne argumenta que sim, porque descobrir um erro óbvio depois de montar um ambiente de teste custa mais caro em tempo e motivação. O gasto maior de tokens compra menos retrabalho.
- Como evitar que a lista de threads vire um cemitério de tarefas? Trate a barra lateral como caixa de entrada e use snooze para o que não é prioridade agora. Browne também vincula PRs a threads para que elas desapareçam automaticamente quando o merge acontecer.
- O fluxo com agentes de IA substitui a revisão humana? Não substitui, desloca o esforço. Browne afirma que erros ainda acontecem e que a nightly existe justamente para capturá-los antes que cheguem à base estável, o que mantém a revisão como parte do processo.
- Por que Linux aparece tanto nesse tipo de fluxo? Browne relata que paralelizar muitas tarefas em macOS é difícil e que prefere tratar o Mac como espaço para uma ou duas tarefas. Em Linux, ele diz nunca ter saturado a máquina fora de cargas muito pesadas.
- Esse modelo de trabalho serve para projetos pequenos? Os princípios servem, a infraestrutura não precisa ser a mesma. Reduzir o atrito de teste, automatizar a auditoria do PR e ter um canal de detecção de falhas funcionam em qualquer tamanho de repositório.
Transforme suas ideias em artigos com o Skala Blog
Este artigo nasceu de uma ideia simples: reduzir o atrito entre o que você sabe e o que você publica. Theo Browne fez isso com código, encurtando o caminho entre observar um problema e ver a correção mergeada. O mesmo raciocínio se aplica a quem tem explicações, entrevistas e opiniões gravadas em vídeo e nunca consegue transformá-las em texto.
Se você produz conteúdo em vídeo, dá para reaproveitar esse material. Basta levar o link até o Skala Blog, transcrever a gravação e gerar um artigo pronto para revisão. O caminho é o mesmo que você viu aqui: tirar o trabalho pesado do meio e concentrar sua atenção no que só você pode decidir.
Cursos e comunidades brasileiras, como o Crazystack, mostram que a base técnica se aprende rápido. O que trava a maioria das pessoas é a etapa de transformar conhecimento em material publicável — e é exatamente aí que vale encurtar o caminho.