Minha configuração para programar com IA: agentes, skills, terminais e worktrees

Hoje em dia, raramente programo uma funcionalidade inteira à mão. Os agentes evoluíram tanto nos últimos dois anos que agora é possível descrever uma funcionalidade completa, como você quer que o código dela seja organizado, e o agente vai escrever toda a lógica. Incluindo os testes.

Por isso, precisei preparar meu ambiente de desenvolvimento local para trabalhar mais rápido e de forma mais inteligente com diferentes agentes, sejam remotos ou locais.

Preciso dizer, porém, que uso menos agentes locais porque leva mais tempo para receber respostas deles e percorrer codebases maiores.

Agentes

Escolha agentes por função

Uso Claude ou Codex para o trabalho e para projetos pessoais, mas não os dois ao mesmo tempo. Minha empresa paga o acesso a um deles e se sente confortável com o fato de eu usá-lo em projetos pessoais, então a disponibilidade também faz parte da decisão. Ambos têm vantagens e desvantagens, mas não atribuo trabalho com base apenas no nome do modelo. Escolho um agente de acordo com o tipo de trabalho que preciso fazer: pesquisa e planejamento, implementação do dia a dia ou revisão.

Para pesquisa e planejamento, uso Fable ou Sol quando preciso que um agente leia documentos, cruze informações e proponha uma solução inicial. Eles também são úteis quando preciso resumir uma conclusão cruzando muitos logs de aplicativos diferentes.

Para trabalho de implementação, quando já sei o caminho a seguir, uso Sonnet ou Luna (Max). Às vezes uso Terra no lugar. Esse é o tipo de tarefa em que forneço o máximo de informação possível: o plano, os arquivos relevantes, a organização esperada dos arquivos e as restrições. Isso me ajuda a passar de um plano claro para a execução sem tratar toda tarefa como um problema de pesquisa.

Para revisões, uso Terra com Opus para revisar meu código e deixar comentários nos pull requests de outras pessoas. O importante não é usar um modelo específico em todas as revisões. É garantir que o agente tenha contexto suficiente para acompanhar a mudança, entender os padrões existentes e apontar lacunas antes de o código ser integrado.

Skills

Scripts do Matt

Conheço o Matt desde que fiz o curso dele no totaltypescript.com. Lá, vi que ele tinha mergulhado fundo em programação com IA nos últimos meses. Foi então que comecei a olhar as skills que ele estava criando, não apenas para ter um ponto de vista técnico, mas também para ajudar o agente a realmente entender a funcionalidade antes de começar a programar.

grill-with-docs

Grill with docs vai modificar o objetivo do agente até que ele consiga entender as regras de negócio que você quer alcançar. Quando há um acordo, ele cria um ADR com o escopo, os objetivos e os conceitos de domínio não escritos para o desenvolvimento futuro com agentes. Com essa skill, a qualidade e o escopo das minhas funcionalidades ficaram muito mais claros, e ela me ajudou a pensar em casos extremos antes de o código ser escrito.

Skill personalizada de commits

Uma skill pessoal que é basicamente um conjunto de instruções para agrupar arquivos ou hunks de acordo com a funcionalidade e então começar a fazer os commits. O agente vai perguntar se o agrupamento faz sentido antes de criar o commit. Ele também vai pedir que você crie uma nova branch quando necessário.

Terminal

Herdr

Meu gerenciador de agentes de terminal favorito é o Herdr. Ele ganhou popularidade recentemente e, para mim, é o próximo passo depois do Tmux. No ano passado, eu usava muito o Tmux. Mas, depois que migrei para o Herdr, não tive problemas para criar novas abas e painéis. Não houve mais erros durante a inicialização do shell no terminal, e o número de plugins cresce a cada dia.

Organização dos painéis

Uso um layout de três painéis desde os tempos do Tmux. O painel da esquerda é o maior e eu o uso para a conversa com o agente porque preciso de espaço para LER. Sim, você leu certo. Para mim, ler é a parte mais importante de trabalhar com um agente; caso contrário, vou vê-lo começar a alucinar se as minhas instruções não forem claras o bastante.

O painel superior direito normalmente é usado para lazygit, assim tenho visibilidade sobre quais arquivos meus agentes estão modificando. Além disso, se for mais rápido e barato fazer o commit eu mesmo, normalmente sou mais rápido digitando o commit do que pedindo ao agente que o faça, especialmente se houver apenas alguns arquivos modificados.

O painel inferior direito é usado para rodar comandos, builds, deploys ou qualquer outro comando de shell que eu queira. Também posso executá-los por meio do agente. Mas, às vezes, enquanto o agente está pensando, prefiro ter a saída visual de um comando que estou executando.

Worktrees

Worktrees com Treehouse

Normalmente, tenho três cópias do mesmo projeto no meu computador. Algumas pessoas diriam que estou desperdiçando espaço em disco. Mas acho que esse é o equilíbrio perfeito para o que quero fazer.

A primeira cópia é para desenvolver funcionalidades. A segunda é para pesquisar logs, cruzar documentação e planejar. A terceira é para experimentos e hotfixes.

Além disso, trabalho com worktrees. Há várias maneiras de trabalhar com worktrees, incluindo ferramentas do Claude e do Codex. Você pode configurar vários agentes para iniciar uma pesquisa usando um worktree, mas precisa manter o link simbólico entre as bibliotecas instaladas, especialmente em projetos TypeScript, e garantir que os mesmos arquivos .gitignore estejam no projeto original e no worktree.

Uso o Treehouse, do Kunchenguid. O Treehouse oferece uma maneira de gerenciar facilmente seus worktrees com hooks e comandos úteis. Além disso, quando o agente lê os comandos do Treehouse, consegue entender como pode trabalhar facilmente com ele.

O Treehouse vai pegar o commit mais recente da sua branch main ou master e começar a trabalhar a partir desse commit. Depois, você pode criar uma nova branch com base nele.

A única desvantagem é que você precisa usar um comando longo:

treehouse

Mas, como já tenho conhecimento de Bash, é bem fácil configurar aliases para alguns dos comandos que mais uso.

alias th="treehouse"
alias ths="treehouse status"
alias the="treehouse enter"

Outro dia, eu estava pensando: quero ter um único comando para abrir uma nova aba do Herdr com um layout - os 50% da esquerda como de costume, com o lado direito dividido horizontalmente.

E, depois de uma sessão de programação com o Codex, foi possível.

# Aba de worktree com Treehouse + Herdr
function treehouse_herdr_tab {
  local name="$1"
  if [[ -z "$name" ]]; then
    echo "usage: thw <name>" >&2
    return 1
  fi
  if ! exist treehouse || ! exist herdr || ! exist jq; then
    echo "thw: requires treehouse, herdr, and jq" >&2
    return 1
  fi
  if [[ -z "$HERDR_WORKSPACE_ID" ]]; then
    echo "thw: must be run from inside a herdr pane" >&2
    return 1
  fi

  local worktree_path
  worktree_path=$(treehouse get --lease --lease-holder="thw:$name") || return 1

  local tab_json root_pane right_pane
  tab_json=$(herdr tab create --workspace "$HERDR_WORKSPACE_ID" --cwd "$worktree_path" --label "🌳 $name" --focus) || return 1
  root_pane=$(jq -r '.result.root_pane.pane_id' <<< "$tab_json")

  right_pane=$(herdr pane split --pane "$root_pane" --direction right --ratio 0.5 --cwd "$worktree_path" | jq -r '.result.pane.pane_id') || return 1
  herdr pane split --pane "$right_pane" --direction down --ratio 0.5 --cwd "$worktree_path" >/dev/null
}

alias thw=treehouse_herdr_tab

Para cada worktree criado por esse fluxo do Treehouse, o script adiciona o emoji 🌳 ao rótulo da aba do Herdr. Isso torna as abas de worktree fáceis de reconhecer entre o restante das minhas sessões.

Usando o alias thw <feature-name>, o Herdr abrirá uma nova aba, dividirá os painéis e entrará automaticamente no worktree em cada um deles. Assim, consigo começar a experimentar ou trabalhar em uma funcionalidade.

Notion

O Notion se tornou meu organizador pessoal para a vida diária, incluindo documentação técnica. Ao longo dos anos, gerenciei tudo por lá: assinaturas pessoais, roteiros de viagem, uma calculadora de despesas mensais, snippets privados de código e conteúdo copiado da internet.

Agora que adicionaram suporte a MCP, conectar meu código ao Notion ficou mais fácil do que nunca: criar resumos de livros de design de sistemas, armazenar snippets de padrões que posso reutilizar em outros projetos e rascunhar as primeiras ideias para meus posts de blog. Tudo fica vinculado e inclui um agente de IA para me ajudar com a gramática antes de eu escrever as versões finais dos posts.

Conclusão

No último ano, meu fluxo de trabalho se concentrou em escrever código o mais rápido possível. Ainda tenho essas ferramentas instaladas, mas hoje mudar meus fluxos para algo mais centrado em IA se tornou parte da minha rotina normal. Cruzar o máximo de informação possível e então criar mais conteúdo com base nela - código e texto - tem sido um truque de produtividade útil para mim. Espero que isso se torne normal para todas as pessoas que também se sentem confortáveis trabalhando com um computador.