Traycer Bart Mode: Testei o Desenvolvimento de IA Guiado por Especificações

Traycer Bart Mode: Testei o Desenvolvimento de IA Guiado por Especificações

Quase fechei a aba.

Estava no terceiro parágrafo de um tópico no Hacker News sobre “orquestradores de codificação agente” quando meu cérebro fez aquele movimento de cansaço — aquele momento em que você já leu a expressão “fim do vibe coding” tantas vezes que uma nova ferramenta se autointitulando o fim do vibe coding acende o mesmo alerta que um e-mail de phishing. Eu já estava pronto para seguir em frente. Então notei o nome no topo do tópico: Traycer. Não Tracer. Não TracerAI. Traycer, escrito de propósito de forma estranha, com um post no blog intitulado "Ralph Loops. Bart Orchestrates."

Esse título me fez parar. Porque o loop Ralph é uma situação real que já enfrentei. Repetidas vezes. E “repetir cegamente até funcionar” descreve exatamente a sensação de ver um loop do Claude Code travando no mesmo caso de teste falho às 2 da manhã enquanto tomo café frio e questiono minhas escolhas de vida.

Então dei 90 minutos ao Traycer. Experimentei o modo Bart em um projeto real — um pequeno dashboard de gerenciamento de agentes com autenticação e integração de API — e rodei em paralelo com um workflow manual e guiado por plano no Claude Code, que é como tenho implementado a maioria dos meus projetos paralelos nos últimos seis meses.

O que encontrei não corresponde ao hype. Também não corresponde ao meu ceticismo. O modo Bart do Traycer realmente faz algo que o loop Ralph não consegue — mas também faz isso de uma forma que muda o significado de “codificação autônoma com IA”, e nem todo projeto se beneficia. Aqui está o passo a passo completo, o que funciona, o que quebra e para quem isso realmente faz sentido.

O Problema do Ralph Loop Ninguém Comenta

Antes de entender por que o modo Bart é relevante, você precisa ter o modelo mental do que ele substitui. Isso começa por compreender o que a maioria das pessoas quer dizer quando fala em “código autônomo por IA” em 2026.

O padrão dominante hoje é o Ralph loop. Nomeado em referência ao Ralph Wiggum de Os Simpsons (aquela criança que insiste, nem sempre com sucesso), o Ralph loop é brutalmente simples: você direciona um agente de codificação IA para uma tarefa, envolve-o em um loop while not done (“enquanto não terminar”), e deixa rodar. Cada iteração começa com um contexto novo, lê um arquivo de plano em disco, tenta executar um bloco de trabalho, verifica, e repete. A filosofia é pura persistência — se uma tentativa falhar, tente de novo com um contexto levemente diferente.

Já rodei Ralph loop em produção. Funciona. E às vezes incrivelmente bem. Uma feature bem delimitada, com bons testes e um único repositório, pode de fato ser entregue do dia para a noite, com o agente processando iteração após iteração. A Vercel Labs mantém uma implementação chamada ralph-loop-agent. O repositório do GitHub snarktank/ralph está entre os projetos de coding autônomo mais estrelados deste ano. O padrão é real e sustenta muitos fluxos de entrega indie atualmente.

Mas aqui está o que nunca aparece nas páginas de vendas. O Ralph loop possui duas fragilidades estruturais — e ambas já me custaram horas reais:

Problema um: tentativas às cegas. Quando o loop falha, ele não sabe por que falhou de um jeito que a próxima iteração possa aproveitar. Ele lê o arquivo de plano, vê “tarefa 4 não concluída”, e tenta a tarefa 4 de novo. Se a tarefa 4 está errada porque o plano estava errado — e não a execução — o loop alegremente vai gerar o mesmo código quebrado por seis horas seguidas. Vi um Ralph loop em um projeto de um amigo consumir 400.000 tokens tentando implementar um endpoint de webhook do Stripe que nem precisava existir, porque a espec havia se desviado da realidade dois tickets antes.

Problema dois: ausência total de camada de orquestração. O Ralph loop é um agente fazendo uma coisa só, num ciclo fechado. Não consegue paralelizar, não escala para intervenção humana no momento certo, e — crucialmente — não consegue ajustar o plano quando a implementação revela algo que o plano não previu. Ele só executa.

Esse segundo problema foi o que finalmente me fez clicar no botão de cadastro do Traycer. Porque o modo Bart — segundo a interpretação do próprio Traycer — não é só mais um Ralph loop com prompts melhores. É outra categoria. Um orquestrador de outer-loop que observa os inner loops, direciona o plano conforme ele evolui e sabe quando é hora de parar e te perguntar algo, ao invés de alucinar uma resposta.

Essa definição pode ser puro marketing. Ou pode ser exatamente o que venho esperando. Só há uma maneira de descobrir.

O Que é Realmente o Traycer Bart Mode

Antes de entrar no teste, o contexto do produto importa, pois "Traycer" é um espaço de nomes concorrido e os detalhes específicos determinam se isso se aplica ao seu fluxo de trabalho.

O Traycer é uma plataforma de desenvolvimento orientada por especificações — ele fica entre você e o seu agente de codificação (Claude Code, Cursor, Windsurf, ou qualquer que você use) e transforma intenções de alto nível em especificações estruturadas e executáveis. A plataforma possui quatro modos de tarefas, e o modo Bart é uma estratégia de execução específica dentro do modo Epic — o maior e mais autônomo do sistema.

Veja como os modos se organizam, do escopo menor ao maior:

• Modo Plan — para tarefas bem delimitadas. Descreva uma alteração, receba um plano de implementação arquivo por arquivo e entregue ao seu agente de codificação. É o modo que concorre mais diretamente com o /plan do Claude Code.
• Modo Phases — para funcionalidades complexas. O Traycer esclarece a intenção, divide o trabalho em fases guiadas no estilo Kanban, planeja cada fase, repassa ao seu agente e verifica os resultados em cada ponto de controle. Este é o quadro de fases estilo Kanban lançado no início de 2026.
• Modo Review — um fluxo de revisão de código agentico. Análise profunda de bugs, performance, segurança e clareza. Você aponta para um diff ou para o estado de um repositório e ele faz o relatório.
• Modo Epic — para gerenciar projetos inteiros. Mantém especificações vivas e um backlog de tickets, permitindo executar em fases controladas ou entregar todo o Epic ao Bart.

O modo Bart é a opção de “entregar todo o Epic”. A documentação do Traycer o chama internamente de Smart YOLO, e o blog público o define como um orquestrador de outer-loop. A diferenciação em relação ao Ralph é explícita na explicação deles: Bart não é um executor rodando num loop apertado. Bart gerencia um sistema de feedback que percorre especificações, tickets, diffs, resultados de verificação e decisões humanas — e adapta o plano conforme o código evolui.

Na prática, isso significa: você descreve um projeto, o Traycer gera as especificações, Bart divide em tickets, Bart executa os tickets em lotes paralelos usando o agente de codificação escolhido, Bart verifica cada lote em relação às especificações depois da execução e Bart continua, atualiza o plano ou escala para você caso encontre uma divergência que não consiga resolver.

A frase-chave na própria descrição do Traycer é aquela à qual sempre retorno: “Quando a implementação conflita com as especificações, Bart não alucina uma nova verdade. Ele para e diz: eis o descompasso. Aqui estão as opções. Escolha a restrição.”

Essa sentença — se for verdadeira — é a diferença entre entregar software e ficar depurando lixo de IA por seis horas. Vamos descobrir.

A Configuração: Projeto Real, Riscos Reais

Eu não queria um teste de brincadeira. Testes de brincadeira favorecem qualquer ferramenta. Por isso, escolhi um projeto que já iria construir este mês de qualquer jeito — um pequeno dashboard interno para gerenciar o agent manager que rodo para um cliente — e executei tudo no modo Bart do Traycer em vez do meu fluxo usual, guiado por planos com o Claude Code.

O briefing do projeto, escrito exatamente como eu faria para um engenheiro de verdade:

Construa um dashboard interno. Next.js 15, TypeScript, Tailwind, shadcn/ui. Autenticação Supabase (email + magic link). Rota protegida em /agents que faz fetch de uma API externa (POST com chave de API do env), exibe agentes em tabela com filtros (status, último run, tipo de agente), permite disparar execução manual. Gráficos de histórico de execuções (recharts). Sem multi-tenancy. Dashboard para operador solo.

Aproximadamente uma semana de trabalho se eu escrevesse tudo. Talvez três dias se rodasse pelo Claude Code com um plano limpo. A questão: o que o modo Bart faria com isso?

Me cadastrei no plano gratuito — o Free da Traycer é US$0/mês com um slot de capacidade e crédito ilimitado para tarefas open-source, e teste Pro de 7 dias para quem quiser capacidade paga. Para este teste, o plano gratuito cobriu bem toda a configuração Epic e os dois primeiros lots de execução antes de cogitar mais paralelismo. Os planos pagos custam US$10/mês Lite, US$25/mês Pro e US$40/mês Pro+ na data deste texto, com 20% de desconto anual.

A escolha do modelo é crucial aqui. O Traycer é agnóstico em relação ao agente — não faz inferência própria, apenas orquestra o agente de código autenticado por você. Rodei o teste com o Claude Opus 4.7 como modelo de execução, que a Anthropic lançou em 16 de abril de 2026, validado no SWE-bench com 87,6% (subindo dos 80,8% do Opus 4.6) e 70% no CursorBench. Se você quer o real limite do coding autônomo orientado por especificações em abril de 2026, essa é a dupla.

Fase Um: Do Brief ao Especificação

A primeira coisa que me pegou de surpresa foi como o Traycer lidou com o brief. Colei o brief em uma nova Épica, adicionei dois arquivos de contexto (a especificação da API do cliente existente e um screenshot básico do wireframe) e esperava que ele começasse imediatamente a gerar tickets. Mas não. Em vez disso, ele me fez sete perguntas — e cada uma delas era exatamente o tipo de questão que eu teria interpretado errado se tivesse pulado essa etapa.

As perguntas, na ordem em que apareceram:

1. A tabela de agentes deve paginar no lado do servidor ou do cliente?
2. Qual o volume esperado de linhas — menos de 100, centenas ou milhares?
3. Quando uma execução manual é disparada, o comportamento esperado é fire-and-forget ou a UI deve mostrar status em tempo real?
4. As chaves de API são por usuário ou globais no workspace?
5. O gráfico de histórico de execuções deve mostrar os N últimos runs, uma janela de tempo, ou ambos com um toggle?
6. Qual o comportamento desejado caso a API externa esteja fora do ar — último estado conhecido em cache, estado vazio, ou um banner?
7. “Tipo de agente” é um enum fixo ou vem da resposta da API?

Todas essas perguntas se transformariam em bugs dois dias após o início da implementação. Especialmente a questão sobre “tipo de agente”: enum fixo ou vindo da API — eu estava assumindo que era um enum. Não era. Só essa suposição teria feito explodir um componente de filtro e obrigado a um refactor.

É isso o que o Traycer chama de esclarecimento em modo Fases, que acontece na configuração da Épica. Não é engenharia revolucionária. O que é, de fato, é um modelo agindo como um engenheiro sênior que já se queimou antes e sabe que tipo de suposição é fatal. A maioria das ferramentas de código assistido por IA pula essa etapa porque perguntas de esclarecimento parecem atrito. O Traycer as transforma no primeiro passo do processo.

Depois que respondi às perguntas, o Traycer gerou as especificações. Plural. Nada de um PRD monolítico, mas sim uma árvore de specs:

• tech-stack.md — Next.js 15 App Router, TypeScript em modo estrito, Tailwind v4, lista de componentes shadcn/ui, setup do cliente Supabase
• data-models.md — Tipos Agent, Run, RunHistory com schemas Zod
• auth-flow.md — fluxo de magic link, middleware de rotas protegidas, manipulação de sessão
• api-integration.md — contratos de endpoint, manipulação de env vars, estratégia de retry/erro
• ui-layout.md — estrutura de rotas, hierarquia de componentes, breakpoints responsivos
• ticket-backlog.md — 14 tickets com critérios de aceite, mapeados para arquivos

É aqui que os fluxos tradicionais Ralph-loop costumam entregar ao agente um único arquivo de plano e seguir adiante. O Traycer fez diferente: mostrou os tickets e perguntou qual caminho de execução eu queria. Executar em Fases (checkpoints controlados entre cada fase) ou delegar para o Bart (autônomo, ponta a ponta).

Escolhi o Bart.

Fase Dois: Bart Assume o Volante

No momento em que você entrega um Epic ao Bart, a interface muda. O quadro de tickets se transforma em uma visualização de orquestração. Você vê o Bart puxando tickets em lotes — agrupados por dependência, não por ordem na lista — e despachando-os em paralelo.

No meu projeto, o primeiro lote consistiu em quatro tickets executados simultaneamente:

• T-01 — Estrutura do projeto + configuração do Tailwind + shadcn
• T-02 — Cliente Supabase + integração de variáveis de ambiente
• T-03 — Definições de tipos + schemas Zod
• T-04 — Módulo de cliente de API com lógica de tentativa e repetição

Esses quatro não possuem dependências cruzadas — todos podem ser executados em paralelo. Um loop Ralph teria executado cada um sequencialmente, me custando aproximadamente quatro vezes mais tempo de relógio. Bart executou todos em paralelo, com quatro sessões separadas do Claude Opus 4.7 em quatro branches isolados. Tempo total para o primeiro lote: onze minutos.

Então aconteceu algo que realmente me fez inclinar para mais perto da tela.

Depois que o primeiro lote terminou, Bart não despachou imediatamente o segundo lote. Ele executou uma verificação. Não apenas “o código compilou” — uma verificação real de especificação. Ele leu os arquivos gerados, comparou com a árvore de especificações, e sinalizou dois problemas:

1. O módulo cliente da API utilizou uma contagem de tentativas igual a 3 com backoff exponencial. A especificação api-integration.md determinava 5 tentativas com intervalos fixos de 2 segundos. Bart identificou isso.
2. O schema Zod para Agent.status utilizava uma união de strings. A especificação derivada da minha resposta de esclarecimento dizia que deveria vir da resposta da API, e não de uma união fixa. Bart identificou isso.

Então — e é aqui que mora o diferencial — Bart atualizou os tickets do segundo lote para incluir correções para essas inconsistências, ao invés de despachar o lote dois em cima de uma base quebrada. Ele adicionou dois sub-tickets ao backlog: T-04b (corrigir configuração de retry) e T-03b (deixar agent.status dinâmico), puxou ambos para o segundo lote e só então prosseguiu.

É isso que “orquestrador” realmente significa na prática. Não é paralelismo pelo paralelismo. É paralelismo com verificação em ciclo fechado contra uma especificação viva, com a capacidade de adaptar o plano durante a execução. O loop Ralph não consegue fazer isso. Não porque seus autores não pensaram nisso — mas porque a arquitetura não permite. O loop Ralph não tem visão de comparação entre especificação e implementação. O Bart tem.

O Momento em Que Bart Parou e Fez uma Pergunta

O terceiro lote foi onde vi o que o blog do Traycer quer dizer com "Bart não alucina uma nova verdade."

O lote incluía T-09 (gráfico do histórico de execuções) e T-10 (botão de disparo manual). Ambos foram concluídos. A verificação do Bart sinalizou um conflito: o ticket do gráfico assumia que o histórico de execuções vinha de um cache do banco de dados local (derivado da estratégia de cache do api-integration.md), mas o ticket do disparo manual assumia que ele invalidava o cache e buscava novamente na API externa (derivado da minha resposta de esclarecimento sobre status em tempo real).

Ambas as interpretações estavam alinhadas com partes diferentes das especificações. Ambas eram coerentes. Mas não poderiam coexistir — uma teria que ceder.

Um loop do Ralph teria escolhido uma. Silenciosamente. E eu só descobriria a inconsistência em duas semanas, quando o histórico de execuções parasse de atualizar após um disparo manual.

Bart interrompeu o Epic e exibiu um cartão de decisão na interface. O cartão mostrava a divergência, as duas interpretações e três propostas de resolução (invalidar o cache ao acionar, não invalidar mas mostrar atualização otimista, sempre buscar dados ao vivo para o gráfico). Eu escolhi uma. Bart atualizou a especificação, regenerou o ticket afetado e continuou.

Tempo total do humano gasto nessa decisão: talvez 90 segundos. Tempo total economizado: provavelmente uma sessão inteira de depuração daqui a duas semanas.

Se você prefere ter um time cuidando disso de ponta a ponta, em vez de aprender mais uma ferramenta, eu assumo projetos de Claude Code e orquestração de agentes via Fiverr — construir esse tipo de workflow orientado a especificações é o principal que entrego hoje em dia para clientes.

Fase Três: A Linha de Chegada e o que o Bart Deixou Passar

Noventa e três minutos de tempo corrido após eu entregar o Epic ao Bart, o dashboard estava funcionalmente completo. Autenticação funcionando. Tabela de agentes renderizando. Filtros operacionais. Gráfico exibindo dados. Trigger manual disparando. Comando local npm run dev iniciado sem erros.

Isso parece uma volta da vitória. Não é bem assim.

Veja o que precisei corrigir manualmente após o Bart reportar "Epic completo":

Uma regressão de estilo. O componente Select do shadcn/ui na barra de filtros usava o estilo padrão, que não combinava com o restante do dashboard. A especificação não detalhou — o Bart inferiu o padrão — mas a inferência foi equivocada. 4 minutos para corrigir.

Uma decisão de UX. O estado vazio da tabela de agentes — quando a API externa retornava zero agentes — usava uma mensagem genérica de "No results". Um ser humano de verdade teria escrito algo mais específico ("Nenhum agente encontrado. Adicione seu primeiro agente no painel de configurações.") O Bart escreveu o literal que a especificação sugeria e nada além disso. 3 minutos para ajustar.

Uma questão de segurança. A chave de API foi corretamente obtida das variáveis de ambiente no código do servidor, mas o componente do cliente que acionava execuções manuais fazia um fetch para /api/agents/run sem proteção contra CSRF. A especificação não exigia CSRF. O Bart não adicionou. Para um dashboard interno de operador único, tudo bem. Para produção em equipe, não seria suficiente. 8 minutos para adicionar o middleware.

Sem testes. O Bart não escreve testes a não ser que a especificação peça explicitamente. A minha não pediu. Adicionei os mais críticos manualmente (redirect de autenticação, tratamento de erro de API). 22 minutos.

Tempo total de retoques manuais: aproximadamente 40 minutos. Não é zero. Não é trivial. Mas o projeto foi do briefing ao “pronto para mostrar ao cliente” em pouco mais de duas horas e meia no total, e eu estava fazendo outros trabalhos durante boa parte desse tempo.

Para comparar, meu workflow manual usando Claude Code orientado por planejamento, em um projeto de escopo semelhante mês passado, levou cerca de quatro horas focado codificando ao vivo, mais duas horas na manhã seguinte para os ajustes finais. O modo Bart condensou isso em uma única sessão, onde eu estava basicamente só acompanhando.

Modo Bart vs Claude Code: Quando Usar Cada Um

Eu não acho que o modo Bart substitui o Claude Code. Eu uso ambos agora, e a pergunta que comecei a fazer antes de cada projeto é: este projeto tem área de atuação suficiente para que o desenvolvimento orientado por especificação valha a pena?

Aqui está a árvore de decisão que estou utilizando após três semanas com o Traycer:

Use o modo Bart quando:

• O projeto possui 5+ componentes distintos ou tickets
• Diversas partes podem ser paralelizadas sem cruzar estado
• A especificação pode ser escrita claramente (novos recursos, aplicações greenfield, migrações bem delimitadas)
• Você quer sair do projeto e retornar a algo funcional
• Você tem uma licença paga do Traycer com capacidade para paralelizar

Use o Claude Code manualmente quando:

• A tarefa é um único arquivo ou uma única responsabilidade
• Você está em modo exploratório ou de pesquisa e ainda não sabe qual é o estado final
• A base de código existente tem convenções implícitas suficientes que as specs não capturariam
• Você quer tomar todas as decisões em tempo real (modo pareamento)
• A tarefa exige que você reaja a erros no contexto, o que specs não conseguem capturar

Use ambos no mesmo fluxo de trabalho quando:

• O Bart cuida do scaffolding + tickets estruturais
• Você assume no Claude Code para o refinamento de UX, testes e tudo o que as specs não conseguem descrever
• Essa é, na verdade, a combinação que estou rodando agora

O interessante sobre essa divisão é que o modo Bart não piora o Claude Code — ele deixa mais claro para que serve o Claude Code. Claude Code é um instrumento cirúrgico. Modo Bart é o andaime para estruturas maiores. Eu estava usando o instrumento cirúrgico para construir andaimes, por isso sessões plan-driven de seis horas pareciam um fardo mesmo quando entregavam resultado.

O Que Ninguém Está Escrevendo Sobre Desenvolvimento Orientado por Especificações

Três semanas depois, aqui estão os pontos sobre desenvolvimento de IA orientado por especificações que não encontro nas páginas dos produtos nem nos demos do YouTube.

Especificações são mais difíceis de escrever do que código. Eu sei. É o oposto do discurso comercial. Mas redigir uma boa especificação — uma que seja inequívoca, completa e autoconsistente — requer um grau de clareza de produto que a maioria dos desenvolvedores solo não tem no início de um projeto. As perguntas de esclarecimento do Traycer ajudam. Não substituem a habilidade. Se você não consegue responder "isso deve paginar no servidor ou no cliente" em 2026, o Traycer não vai te ensinar a pensar produto. Ele só vai parar e perguntar com mais frequência.

O teto de paralelismo é menor do que o marketing sugere. Grafos de dependência entre tickets se achatam rapidamente. No meu projeto de dashboard, o primeiro lote teve quatro tickets em paralelo. O segundo lote teve dois. O terceiro lote, um. Quando você chega na metade de um Épico, a maioria dos tickets restantes depende de trabalhos anteriores e passa a rodar de forma sequencial. A narrativa dos "agentes paralelos" é real no começo e se esvai no final.

Drift de especificação é o novo drift de código. Quando o Bart atualiza a especificação em pleno andamento para resolver um desencontro, essa mudança se propaga para os tickets restantes. O que é ótimo — até você perceber que sua especificação viva já evoluiu bastante em relação àquela que você aprovou no início. No meu projeto, o api-integration.md passou por três revisões durante a execução. A especificação final ficou melhor do que a inicial, mas não era aquela que eu tinha aprovado. É preciso revisar o estado final da especificação, não só o original. O Traycer facilita isso. Ainda é trabalho.

O Bart ainda se beneficia de momentos de “rubber duck” humano. Duas vezes durante o Épico, pausei o Bart não porque estivesse falhando, mas porque ao observar o fluxo de tickets percebi algo sobre o produto que quis refletir na especificação. A capacidade do Bart de parar e adaptar no meio do Épico é exatamente o que torna essas pausas triviais. Num loop Ralph, pausar significa reiniciar. No modo Bart, pausar é de primeira classe.

O modelo importa tanto quanto o orquestrador. Rodei o mesmo Épico duas vezes — uma com Claude Opus 4.7 como agente executor, outra com GPT-5.4. Mesma especificação, mesma lógica Bart, resultados diferentes. O Opus 4.7 gerou estruturas de componentes mais limpas e captou mais convenções implícitas da especificação. O GPT-5.4 foi mais rápido e ligeiramente mais literal. O orquestrador só é tão bom quanto o agente que despacha. Escolha o modelo primeiro, depois deixe o Bart fazer o resto.

Onde Isso se Encaixa no Cenário de Desenvolvimento Baseado em Especificações

O Traycer não está sozinho nesse espaço. Em 2026, desenvolvimento baseado em especificações tornou-se uma categoria consolidada. As ferramentas que testei este ano:

• Kiro — IDE integrada ao ecossistema AWS com fluxo de trabalho baseado primeiramente em especificação. Forte para projetos do zero com specs bem definidas. Integração intensa com AWS. Excelente se você já está nesse ecossistema.
• GitHub Spec Kit — CLI que adiciona comandos slash orientados por especificação ao Claude Code, Gemini CLI, Cursor e Windsurf. Portável entre agentes, sem dependência de fornecedor, mas você precisa compor o próprio fluxo.
• BMAD-METHOD — metodologia open-source + CLI. Rigorosa. Com um quê acadêmico. Possui curva de aprendizado.
• Traycer — o que tenho usado na maioria dos projetos atualmente. Camada de orquestração mais robusta dentre todas que testei. Agnóstico em relação ao agente. Sepação clara entre autoria da especificação e execução.

A vantagem do Traycer não está no formato da especificação — e sim no que ocorre após a definição da spec. A combinação do modo Epic + orquestrador Bart forma o ciclo de ponta a ponta mais refinado que já utilizei. A criação de specs no Kiro é, talvez, mais limpa. A portabilidade do Spec Kit é, possivelmente, superior. Mas nenhum deles oferece a reconciliação ao vivo entre especificação e implementação como o Bart.

Se você quiser entender melhor a teoria por trás desse padrão, minha postagem anterior sobre o método claude.md skills install do Karpathy explora como arquivos de contexto em formato de spec elevam a qualidade do output de qualquer agente, não só do Traycer. E o comparativo que fiz entre o Ultra Plan do Claude Code e o modo local plan oferece contexto útil sobre como fluxos baseados em planos se comportam em relação aos baseados em specs especificamente dentro do ecossistema Anthropic.

Como Estou Usando o Modo Bart Este Mês

Workflow concreto, caso queira copiar:

Segunda de manhã. Escreva um Épico no Traycer para a principal feature da semana. Responda às perguntas de esclarecimento. Revise a árvore de specs gerada. Edite as especificações onde o Traycer interpretou errado minhas preferências. Entregue para o Bart.

Segunda à tarde. Trabalhe em outras tarefas. O Bart executa lotes. Recebo notificações na interface quando o Bart eleva alguma decisão. No total, gasto talvez 15 minutos respondendo a cartões de decisão ao longo da tarde.

Terça de manhã. Bart reporta o Épico como concluído. Faço o pull do branch, coloco para rodar localmente, reviso comparando com o spec, corrijo questões que exigem polimento manual, escrevo testes, faço commit.

Resto da semana. Uso o Claude Code para trabalhos cirúrgicos — o polimento, os testes, a redação de UX, bugs pontuais. Coisas que o Bart não consegue especificar de forma clara o suficiente para executar.

Isso não é “código autônomo por IA substituindo engenharia”. É “código autônomo por IA faz o esqueleto, eu cuido do acabamento”. Essa divisão parece sustentável de um jeito que o ciclo puro Ralph nunca foi para mim. O ciclo Ralph sempre foi uma aposta tudo ou nada. O modo Bart torna a autonomia parcial, estruturada e — fundamentalmente — reversível. Cada lote pode ser revisado antes do próximo ser disparado. Cada edição de spec é registrada. Todo ticket é reproduzível.

Perguntas Frequentes

O que é o modo Bart do Traycer?

O modo Bart do Traycer é um orquestrador autônomo de outer-loop que executa Epics de projeto inteiras de ponta a ponta, dividindo-as em tickets, rodando esses tickets em lotes paralelos com agentes de codificação de IA, verificando-os contra as especificações após cada lote e adaptando o plano em tempo real quando a implementação revela divergências. Ele roda dentro do Epic mode do Traycer e é agnóstico ao agente — você escolhe o modelo de execução (Opus 4.7, GPT-5.4, etc).

Como o modo Bart é diferente do loop Ralph?

O loop Ralph simplesmente repete uma tarefa até que a verificação seja aprovada, sem entender o motivo de uma falha. O modo Bart é consciente: ele mantém uma spec viva, compara a implementação com a spec após cada lote, adapta os tickets quando há divergência e escala para humanos quando encontra um problema que não consegue resolver. Ralph é um loop while not done. Bart é um orquestrador com memória.

Quais modelos de IA o Traycer suporta?

O Traycer é agnóstico ao agente — não executa inferência própria, apenas orquestra qualquer agente de codificação autenticado por você. Atualmente, isso inclui Claude Code (com variantes Opus 4.7 e Sonnet), GPT-5.4, Cursor e integrações Windsurf. Você escolhe o modelo para cada Epic, dependendo do seu balanço entre velocidade, custo e qualidade.

O Traycer é gratuito?

Sim. O Traycer possui um plano gratuito por $0/mês com capacidade de um slot e teste Pro de 7 dias. Os planos pagos custam $10/mês (Lite), $25/mês (Pro) e $40/mês (Pro+) no momento desta publicação, com planos anuais com 20% de desconto. O plano gratuito é suficiente para testar o modo Bart em um Epic pequeno.

Quando NÃO devo usar o modo Bart?

Evite o modo Bart para edições em um único arquivo, pesquisas exploratórias nas quais você ainda não conhece o resultado final ou codebases com convenções implícitas que specs não captam. Usar Claude Code manualmente é melhor para intervenções pontuais e pair programming em tempo real. O modo Bart brilha quando um projeto tem 5+ tickets com dependências claras e pode ser totalmente descrito como uma spec.

Vamos Trabalhar Juntos

Quer desenvolver sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura tecnológica? Adoraria ajudar.

• Fiverr (soluções sob medida & integrações): fiverr.com/s/EgxYmWD
• Portfólio: mejba.me
• Ramlit Limited (soluções empresariais): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (serviços de segurança): xcybersecurity.io