Traycer Bart Mode: Probé el desarrollo AI guiado por especificaciones

Traycer Bart Mode: Probé el desarrollo AI guiado por especificaciones

Casi cierro la pestaña.

Llevaba tres párrafos de un hilo en Hacker News sobre "orquestadores de codificación agentica" cuando mi cerebro hizo ese gesto de ojos cansados — el típico después de leer la frase "el fin del vibe coding" tantas veces que cualquier nueva herramienta que se autoproclama el fin de vibe coding provoca el mismo reflejo que un correo de phishing. Estaba listo para pasar de largo. Entonces noté el nombre en la parte superior del hilo: Traycer. No Tracer. No TracerAI. Traycer, escrito raro a propósito, con una entrada de blog titulada "Ralph Loops. Bart Orchestrates."

Ese título me detuvo. Porque el bucle de Ralph es algo real que he ejecutado. Repetidas veces. Y “volver a intentar a ciegas hasta que funcione” describe exactamente la sensación de ver a un bucle de Claude Code atorarse con el mismo caso de prueba fallido a las 2 de la mañana mientras tomo café frío y cuestiono mis decisiones de vida.

Así que le di a Traycer sus 90 minutos. Recorrí el modo Bart en un proyecto real — un panel para gestión de agentes con autenticación e integración de API — y lo ejecuté en paralelo frente a un flujo de trabajo manual, basado en planes, en Claude Code, que es con lo que he desarrollado la mayoría de mis proyectos paralelos en los últimos seis meses.

Lo que encontré no coincidió con la expectativa. Pero tampoco con mi escepticismo. El modo Bart de Traycer realmente hace algo que el bucle de Ralph no puede — pero también lo hace de una forma que cambia lo que realmente significa "codificación autónoma con IA", y no todos los proyectos se benefician. Aquí tienes el recorrido completo, lo que funciona, lo que falla y para quién está realmente pensado.

El problema del Ralph Loop del que nadie habla

Antes de comprender por qué importa el modo Bart, necesitas el modelo mental de lo que está reemplazando. Y eso empieza por entender a qué se refiere la mayoría cuando habla de "codificación autónoma con IA" en 2026.

El patrón dominante hoy es el Ralph loop. Nombrado así por Ralph Wiggum de Los Simpson (el niño que sigue intentando, aunque no siempre logre el resultado esperado), el Ralph loop es brutalmente simple: apuntas un agente de codificación IA hacia una tarea, lo envuelves en un bucle while not done y dejas que corra. Cada iteración comienza con un contexto fresco, lee un archivo de plan desde el disco, intenta avanzar en una parte del trabajo, verifica y vuelve a repetir el ciclo. La filosofía es pura persistencia: si un intento falla, lo vuelve a intentar con un contexto ligeramente diferente.

He ejecutado Ralph loops en producción. Funcionan. A veces increíblemente bien. Una característica con un alcance bien definido, buenas pruebas y un solo repositorio puede lanzarse de verdad en una noche, con el agente puliendo iteración tras iteración. Vercel Labs distribuye una implementación de ralph-loop-agent. El repositorio de GitHub snarktank/ralph ha sido uno de los repositorios de codificación autónoma con más estrellas este año. El patrón es real y, ahora mismo, es fundamental para muchos flujos de trabajo indie que buscan lanzar productos rápido.

Pero hay algo que nadie pone en las páginas de ventas. El Ralph loop tiene dos debilidades estructurales, y ambas me han costado horas reales:

Problema uno: reintentos a ciegas. Cuando el bucle falla, no sabe por qué falló de un modo que la siguiente iteración pueda aprovechar. Lee el archivo de plan, ve "tarea 4 no completada" e intenta la tarea 4 de nuevo. Si la tarea 4 es incorrecta porque el plan era incorrecto —y no porque la ejecución fuera incorrecta— el bucle va a regenerar con alegría el mismo código roto durante seis horas seguidas. Vi un Ralph loop en el proyecto de un amigo consumir 400.000 tokens intentando implementar un endpoint de webhook para Stripe que no hacía falta, porque la especificación se había desviado de la realidad dos tickets antes.

Problema dos: sin capa de orquestación. El Ralph loop es un único agente haciendo una sola cosa en un círculo cerrado. No puede paralelizar, no puede escalar a un humano en el momento adecuado y, críticamente, no puede adaptar el plan cuando la implementación revela algo que el plan no había previsto. Solo sabe ejecutar.

Ese segundo problema fue el que me llevó a pulsar el botón de registro en Traycer. Porque el modo Bart —según la propia visión de Traycer— no es otro Ralph loop con mejores prompts. Es una categoría diferente. Un orquestador de bucle externo que observa los bucles internos, dirige el plan según evoluciona y sabe cuándo detenerse y consultarte, en vez de alucinar una respuesta.

Quizás ese enfoque sea solo marketing. O quizás sea lo que he estado esperando. Solo hay una forma de averiguarlo.

Qué es realmente el Modo Bart de Traycer

Antes de entrar en las pruebas, el contexto del producto es importante, porque "Traycer" es un nombre bastante común y los detalles específicos determinan si esto aplica o no a tu flujo de trabajo.

Traycer es una plataforma de desarrollo dirigido por especificaciones: se sitúa entre tú y tu agente de código (Claude Code, Cursor, Windsurf, o el que uses) y transforma la intención de alto nivel en especificaciones estructuradas y ejecutables. La plataforma tiene cuatro modos de tarea, y el modo Bart es una estrategia de ejecución específica dentro del modo Epic, el más grande y autónomo de todo el sistema.

Así es como se componen los modos, desde el alcance más pequeño hasta el más amplio:

• Modo Plan — para tareas bien definidas. Describes un cambio, recibes un plan de implementación archivo por archivo y se lo entregas a tu agente de código. Este modo compite directamente con el /plan de Claude Code.
• Modo Fases — para funcionalidades complejas. Traycer aclara la intención, divide el trabajo en fases guiadas estilo Kanban, planifica cada fase, delega a tu agente y verifica los resultados en cada punto de control. Este es el tablero de fases estilo Kanban que se lanzó a principios de 2026.
• Modo Revisión — un flujo de revisión de código agentico. Análisis profundo para encontrar bugs, problemas de rendimiento, seguridad y claridad. Lo apuntas a un diff o al estado de un repo y te entrega un informe.
• Modo Epic — para gestionar proyectos completos. Mantiene especificaciones vivas y un backlog de tickets, te permite ejecutar por fases controladas o delegar todo el Epic a Bart.

El modo Bart es la opción “delegar todo el Epic”. En la documentación interna de Traycer lo llaman Smart YOLO, y en el blog público lo describen como un orquestador de outer-loop. Hay una distinción explícita respecto a Ralph: Bart no es un trabajador que ejecuta en bucle cerrado. Bart gestiona un sistema de retroalimentación entre especificaciones, tickets, diffs, resultados de verificación y decisiones humanas, adaptando el plan a medida que evoluciona el código.

En la práctica, esto significa: describes un proyecto, Traycer genera las especificaciones, Bart las divide en tickets, Bart ejecuta tickets en lotes paralelos usando tu agente de código preferido, Bart verifica cada lote contra las especificaciones tras su ejecución, y Bart o bien continúa, actualiza el plan, o lo escala contigo si encuentra un conflicto que no puede resolver.

La frase clave en la propia descripción de Traycer, a la que siempre vuelvo, es: “Cuando la implementación entra en conflicto con las especificaciones, Bart no alucina una nueva verdad. Se detiene y dice: aquí está el desajuste. Aquí están las opciones. Elige la restricción.”

Esa frase —si es cierta— marca la diferencia entre entregar y tener que depurar resultados erráticos de la IA durante seis horas. Vamos a comprobarlo.

La Configuración: Proyecto Real, Riesgo Real

No quería una prueba de juguete. Las pruebas de juguete halagan a cualquier herramienta. Así que elegí un proyecto que de todas formas iba a desarrollar este mes: un pequeño dashboard interno para gestionar el agent manager que opero para un cliente. Lo ejecuté utilizando el modo Bart de Traycer en lugar de mi flujo de trabajo habitual de Claude Code, orientado por un plan.

El briefing del proyecto, redactado tal como lo haría para un ingeniero real:

Construir un dashboard interno. Next.js 15, TypeScript, Tailwind, shadcn/ui. Autenticación con Supabase (email + magic link). Ruta protegida en /agents que obtiene datos de una API externa (POST usando clave de API desde env), muestra los agentes en una tabla con filtros (estado, última ejecución, tipo de agente), y permite al usuario lanzar una ejecución manual. Gráficas para el historial de ejecuciones (recharts). Sin multi-tenencia. Dashboard para operador único.

Aproximadamente una semana de trabajo si lo desarrollara yo mismo. Quizá tres días si lo pasara por Claude Code con un plan bien definido. La pregunta es: ¿qué hace Bart mode con esto?

Me apunté en el nivel gratuito — el plan Free de Traycer es $0/mes, con una capacidad de un slot y crédito ilimitado para tareas de código abierto, además de una prueba Pro de 7 días si quieres la capacidad de pago. Para esta prueba, el plan gratuito fue suficiente para completar la configuración Epic y los dos primeros lotes de ejecución, antes de necesitar más paralelismo. Los planes de pago cuestan $10/mes Lite, $25/mes Pro y $40/mes Pro+ en el momento de esta publicación, con un 20% de descuento en el anual.

La selección del modelo es importante aquí. Traycer es agnóstico en cuanto a agentes: no ejecuta su propia inferencia, sino que orquesta cualquier agente de código que hayas autenticado. Realicé la prueba con Claude Opus 4.7 como modelo de ejecución, que Anthropic lanzó el 16 de abril de 2026 con una verificación SWE-bench del 87.6% (subiendo desde 80.8% en Opus 4.6) y CursorBench en 70%. Si buscas el verdadero techo del desarrollo autónomo dirigido por especificaciones en abril de 2026, este es el emparejamiento.

Fase Uno: Del Brief al Especificado

Lo primero que me sorprendió fue cómo Traycer manejó el brief. Lo pegué en una nueva Epic, añadí dos archivos de contexto (la especificación actual del API del cliente y una captura de pantalla del wireframe), y esperaba que empezara a generar tickets de inmediato. No lo hizo. En su lugar, me hizo siete preguntas — y cada una de ellas era una pregunta que yo habría respondido mal si me la hubiera saltado.

Las preguntas, en el orden en que llegaron:

1. ¿La tabla de agentes debe paginarse del lado del servidor o del cliente?
2. ¿Cuál es el recuento esperado de filas — menos de 100, cientos o miles?
3. Cuando se dispara una ejecución manual, ¿el comportamiento esperado es “fire-and-forget” o la UI debe mostrar el estado en tiempo real?
4. ¿Las claves API son por usuario o globales para el workspace?
5. ¿El gráfico de historial de ejecuciones debe mostrar las últimas N ejecuciones, una ventana temporal, o ambas cosas con un toggle?
6. ¿Cuál es el comportamiento deseado si el API externo no responde — estado en caché, estado vacío, o un banner?
7. ¿"Tipo de agente" es un enum fijo o viene como respuesta del API?

Cualquiera de esas preguntas se habría convertido en un bug a los dos días de desarrollo. Especialmente la de “¿Tipo de agente es un enum fijo o viene del API?” — yo daba por hecho que sería un enum. No lo es. Ese supuesto habría roto el componente de filtros y obligado a rehacerlo desde cero.

A esto Traycer lo llama aclaración en modo Fases, y se ejecuta dentro de la configuración de la Epic. No es ingeniería revolucionaria. Lo que sí es: un modelo que actúa como un ingeniero senior que ya se ha quemado antes y sabe qué suposiciones son letales. La mayoría de las herramientas de codificación IA se saltan este paso porque las preguntas de aclaración parecen una molestia. Traycer las convierte en la jugada inicial.

Después de que respondí las preguntas, Traycer generó las especificaciones. En plural. No un único PRD monolítico, sino un árbol de specs:

• tech-stack.md — Next.js 15 App Router, TypeScript en modo estricto, Tailwind v4, lista de componentes shadcn/ui, configuración del cliente Supabase
• data-models.md — Tipos Agent, Run, RunHistory con esquemas Zod
• auth-flow.md — flujo de magic link, middleware para rutas protegidas, gestión de sesión
• api-integration.md — contratos de endpoints, manejo de variables de entorno, estrategia de reintentos/errores
• ui-layout.md — estructura de rutas, jerarquía de componentes, breakpoints responsive
• ticket-backlog.md — 14 tickets con criterios de aceptación, mapeados a archivos

En este punto, los flujos de trabajo típicos tipo Ralph-loop suelen entregar al agente un único archivo de plan y listo. Traycer hizo algo distinto: me mostró los tickets y preguntó qué camino de ejecución quería. ¿Ejecutar en Fases (checkpoints controlados entre cada fase) o delegar a Bart (autónomo de principio a fin)?

Elegí Bart.

Fase Dos: Bart toma el control

En el momento en que entregas una Epic a Bart, la interfaz cambia. El tablero de tickets se convierte en una vista de orquestación. Ves a Bart agrupando tickets en lotes (por dependencias, no por el orden de la lista) y despachándolos en paralelo.

Para mi proyecto, el primer lote fueron cuatro tickets ejecutándose simultáneamente:

• T-01 — Scaffold del proyecto + configuración de Tailwind + shadcn
• T-02 — Cliente Supabase + conexión de variables de entorno
• T-03 — Definiciones de tipos + esquemas Zod
• T-04 — Módulo cliente de API con lógica de reintentos

Estos cuatro no tienen dependencias cruzadas: pueden suceder todos en paralelo. Un ciclo Ralph los habría ejecutado de forma secuencial, costándome aproximadamente cuatro veces más en tiempo de reloj. Bart los ejecutó en paralelo, con cuatro sesiones Claude Opus 4.7 separadas, cada una en su propia rama. Tiempo total del primer lote: once minutos.

Entonces ocurrió algo que me hizo acercarme aún más a la pantalla.

Después de que el primer lote finalizó, Bart no despachó inmediatamente el segundo lote. Ejecutó verificación. No solo "¿compila el código?" — verificación real de especificaciones. Leyó los archivos generados, los comparó contra el árbol de especificaciones y detectó dos discrepancias:

1. El módulo cliente de API utilizaba un recuento de reintentos de 3 con retroceso exponencial. La especificación api-integration.md indicaba 5 reintentos con intervalos fijos de 2 segundos. Bart lo detectó.
2. El esquema Zod para Agent.status usaba una unión de cadenas. La especificación derivada de mi respuesta de clarificación indicaba que debía provenir de la respuesta de la API, no de una unión fija. Bart lo detectó.

Luego —y aquí es donde realmente importa— Bart actualizó los tickets del segundo lote para incluir correcciones a estas discrepancias, en vez de lanzar el lote dos sobre cimientos rotos. Añadió dos sub-tickets al backlog: T-04b (corregir configuración de reintentos) y T-03b (hacer que agent.status sea dinámico), los integró en el segundo lote, y luego continuó.

Esto es lo que realmente significa "orquestador" en la práctica. No es paralelismo por el simple hecho de paralelizar. Es paralelismo más verificación en lazo cerrado frente a una especificación viva, con la capacidad de adaptar el plan en tiempo real. El ciclo Ralph no puede hacer esto. No porque sus autores no lo hayan pensado, sino porque la arquitectura no lo permite. El ciclo Ralph no tiene una vista de especificación contra implementación. Bart sí.

El Momento en que Bart se Detuvo y Hizo una Pregunta

El tercer lote fue donde vi a qué se refería el blog de Traycer con “Bart no alucina una nueva verdad”.

El lote incluía T-09 (gráfico de historial de ejecuciones) y T-10 (botón de activación manual). Ambos se completaron. La verificación de Bart marcó un conflicto: el ticket del gráfico asumía que el historial de ejecuciones provenía de una caché local de la base de datos (derivado de la estrategia de caché de api-integration.md), pero el ticket de activación manual asumía que este proceso invalidaba la caché y volvía a obtener datos de la API externa (derivado de mi respuesta de aclaración sobre el estado en tiempo real).

Ambas interpretaciones eran coherentes con distintas partes de la especificación. Ambas tenían sentido. Pero no podían coexistir: una de las dos debía ceder.

Un bucle tipo Ralph habría escogido una. En silencio. Y yo habría descubierto la inconsistencia dentro de dos semanas, cuando el historial de ejecuciones dejara de actualizarse tras una activación manual.

Bart detuvo el Epic y mostró una tarjeta de decisión en la interfaz. La tarjeta contenía la discrepancia, las dos interpretaciones y tres propuestas de resolución (invalidar caché al activar, no invalidar pero mostrar actualización optimista, o recuperar siempre en tiempo real para el gráfico). Elegí una. Bart actualizó la especificación, regeneró el ticket afectado y reanudó la ejecución.

Tiempo total dedicado por humanos a esa decisión: quizá 90 segundos. Tiempo total ahorrado: probablemente toda una sesión de depuración dentro de dos semanas.

Si prefieres que un equipo se encargue de esto de principio a fin en vez de aprender otra herramienta, asumo proyectos de orquestación de Claude Code y agentes a través de Fiverr — construir este tipo de flujo de trabajo impulsado por especificaciones para clientes es esencialmente lo que más envío hoy en día.

Fase Tres: La meta final y lo que Bart pasó por alto

Noventa y tres minutos de tiempo real después de entregarle el Epic a Bart, el dashboard estaba funcionalmente completo. Autenticación funcionando. Tabla de agentes renderizándose. Filtros operativos. Gráfica mostrando datos. Disparador manual ejecutándose. npm run dev local arrancando sin problemas.

Eso suena a vuelta de victoria. No lo es del todo.

Esto fue lo que tuve que corregir manualmente después de que Bart informara “Epic completo”:

Una regresión de estilos. El componente Select de shadcn/ui en la barra de filtros usaba el estilo por defecto, que no coincidía con el resto del dashboard. La especificación no lo detallaba —Bart dedujo el valor por defecto—, pero la inferencia fue errónea. 4 minutos para arreglarlo.

Una decisión de UX. El estado vacío para la tabla de agentes —cuando la API externa devolvía cero agentes— usaba el mensaje genérico “No results”. Un humano escribiría algo más concreto (“No se encontraron agentes. Agrega tu primer agente desde el panel de configuración.”). Bart escribió literalmente lo que la spec sugería y nada más. 3 minutos para ajustar.

Un detalle de seguridad. La clave de la API se obtenía correctamente de las variables de entorno en el código del servidor, pero el componente cliente que disparaba las ejecuciones manuales realizaba una petición fetch a /api/agents/run sin protección CSRF. La especificación no requería CSRF. Bart no lo añadió. Para un dashboard interno de un único operador esto está bien. Para cualquier producto que salga a un equipo, no lo estaría. 8 minutos para agregar el middleware.

Sin tests. Bart no escribe tests a menos que la especificación lo solicite. La mía no lo hacía. Añadí manualmente los tests críticos (redirección de autenticación, manejo de errores en la API). 22 minutos.

Tiempo total de retoques manuales: aproximadamente 40 minutos. No es cero. No es trivial. Pero el proyecto pasó de especificación a “listo para mostrar al cliente” en apenas dos horas y media en total, y la mayor parte de ese tiempo estuve haciendo otras tareas.

A modo de comparación, mi flujo de trabajo manual usando Claude Code, basado en planificación y para un proyecto de alcance similar el mes pasado, me tomó unas cuatro horas de codificación enfocada, más otras dos horas a la mañana siguiente para limpiar detalles. El modo Bart comprimió todo eso en una sola sesión donde, la mayor parte del tiempo, solo estuve observando.

Modo Bart vs Claude Code: Cuándo usar cada uno

No creo que el modo Bart reemplace a Claude Code. Ahora utilizo ambos, y la pregunta que he empezado a hacerme antes de cada proyecto es: ¿tiene este proyecto suficiente amplitud para que el desarrollo guiado por especificaciones valga la pena?

Este es el árbol de decisión que estoy usando tras tres semanas con Traycer:

Usa el modo Bart cuando:

• El proyecto tiene 5 o más componentes o tickets distintos
• Varias partes pueden paralelizarse sin interferir con estado compartido
• La especificación puede redactarse de forma clara (nuevas funcionalidades, apps desde cero, migraciones bien delimitadas)
• Quieres poder dejar el proyecto y volver después a algo que funcione
• Dispones de una suscripción de pago de Traycer con capacidad de paralelización

Usa Claude Code manualmente cuando:

• La tarea implica solo un archivo o una única preocupación
• Estás en fase exploratoria o de investigación y aún no conoces el estado final
• La base de código existente tiene suficientes convenciones implícitas que una especificación pasaría por alto
• Quieres tomar cada decisión en tiempo real (modo pair-programming)
• La tarea exige reaccionar a errores en un contexto que una especificación no puede capturar

Usa ambos en el mismo flujo de trabajo cuando:

• Bart se encarga del scaffolding y tickets estructurales
• Tomas el control en Claude Code para el pulido UX, tests y las partes que la especificación no puede describir
• De hecho, esta es la combinación con la que estoy entregando proyectos ahora mismo

Lo interesante de esta división es que el modo Bart no empeora Claude Code; hace más evidente para qué sirve realmente Claude Code. Claude Code es un instrumento quirúrgico. El modo Bart es el andamiaje para estructuras más grandes. Yo estaba usando el instrumento quirúrgico para construir andamiajes, y por eso las sesiones de seis horas orientadas a planificación resultaban tan pesadas, incluso cuando entregaban resultados.

De lo que nadie más está hablando en el desarrollo orientado a especificaciones

Tras tres semanas, aquí están los aspectos del desarrollo AI orientado a especificaciones que no veo ni en las páginas de producto ni en las demos de YouTube.

Las especificaciones son más difíciles de escribir que el código. Lo sé. Es justo lo contrario de la propuesta de valor. Pero escribir una buena especificación —una que sea inequívoca, completa y autoconsistente— exige un nivel de claridad sobre el producto que la mayoría de los desarrolladores individuales no tienen al comenzar un proyecto. Las preguntas de clarificación de Traycer ayudan, pero no sustituyen la habilidad. Si no puedes responder "¿esto debería paginarse del lado del servidor o del cliente?" en 2026, Traycer no te enseñará a pensar en producto. Simplemente parará y preguntará más seguido.

El techo de paralelismo es más bajo de lo que sugiere el marketing. Los grafos de dependencia entre tickets se aplanan rápido. En mi proyecto de panel de control, el primer lote tenía cuatro tickets en paralelo. El segundo tuvo dos. El tercero, uno. Cuando llevas medio Epic, la mayoría de los tickets restantes dependen del trabajo previo y se ejecutan de forma secuencial. La historia de los "agentes en paralelo" es real al principio, pero se desvanece hacia el final.

La deriva de la especificación es la nueva deriva del código. Cuando Bart actualiza la especificación en pleno vuelo para resolver un desajuste, ese cambio se propaga al resto de tickets. Lo cual está bien, hasta que te das cuenta de que tu especificación "viva" ha evolucionado considerablemente respecto a la que aprobaste al inicio. En mi proyecto, api-integration.md pasó por tres revisiones durante la ejecución. La especificación final era mejor que la inicial, pero no era la que firmé. Hay que revisar el estado final de la especificación, no solo el original. Traycer lo facilita. Sigue siendo trabajo.

Bart sigue beneficiándose de los momentos 'pato de goma' humanos. En dos ocasiones durante el Epic, pausé Bart, no porque estuviera fallando, sino porque al observar el flujo de tickets se me ocurrió algo sobre el producto que quise reflejar en la especificación. La capacidad de Bart para detenerse y adaptarse a mitad del Epic es justo la función que convierte estas pausas en algo barato. En un bucle Ralph, pausar significa reiniciar. En modo Bart, pausar es de primera clase.

El modelo importa tanto como el orquestador. Ejecuté el mismo Epic dos veces: una con Claude Opus 4.7 como agente de ejecución y otra con GPT-5.4. Misma especificación, misma lógica Bart, resultados distintos. Opus 4.7 generó estructuras de componentes más limpias y captó más convenciones implícitas de la especificación. GPT-5.4 fue más rápido y ligeramente más literal. El orquestador solo es tan bueno como el agente al que despacha. Elige primero el modelo y luego deja que Bart haga lo suyo.

Dónde encaja esto en el panorama de desarrollo dirigido por especificaciones

Traycer no está solo en este espacio. En 2026, el desarrollo dirigido por especificaciones se ha convertido en una verdadera categoría. Las herramientas que probé este año:

• Kiro — IDE próximo a AWS con workflow orientado a especificaciones desde el inicio. Sólido para proyectos greenfield con especificaciones bien definidas. Integración profunda con AWS. Excelente si formas parte de ese ecosistema.
• GitHub Spec Kit — CLI que añade comandos orientados a especificaciones a Claude Code, Gemini CLI, Cursor, Windsurf. Portabilidad entre agentes, sin bloqueo de proveedor, pero eres tú quien compone el flujo de trabajo.
• BMAD-METHOD — metodología open-source + CLI. Muy rigurosa. Sensación académica. Requiere curva de aprendizaje.
• Traycer — la herramienta que utilizo para la mayoría de proyectos actualmente. La capa de orquestación más potente que he probado. Agnóstica en cuanto a agentes. Clara separación entre la creación de especificaciones y su ejecución.

La ventaja de Traycer no está en el formato de su especificación, sino en lo que sucede después. La combinación del modo Epic + orquestador Bart ofrece el ciclo de feedback end-to-end más cerrado que he usado. La creación de especificaciones en Kiro es, posiblemente, más limpia. La portabilidad de Spec Kit puede ser superior. Ninguno, sin embargo, posee la reconciliación en vivo entre especificación e implementación que tiene Bart.

Si te interesa la teoría detrás de este patrón, mi publicación previa sobre el método de instalación de skills con claude.md de Karpathy explica cómo los archivos de contexto estilo especificación mejoran la calidad del output de cualquier agente, no solo el de Traycer. Además, la comparativa que realicé entre el Ultra Plan de Claude Code y el modo plan local es un contexto útil para ver cómo los flujos de trabajo guiados por planes se comparan con los dirigidos por especificaciones, especialmente dentro del ecosistema de Anthropic.

Cómo estoy usando Bart Mode este mes

Flujo de trabajo concreto, si quieres copiarlo:

Lunes por la mañana. Escribe una Epic en Traycer para la funcionalidad principal de la semana. Responde a las preguntas de aclaración. Revisa el árbol de especificaciones generado. Edita las especificaciones donde Traycer se equivocó sobre mis preferencias. Entrega a Bart.

Lunes por la tarde. Haz otras cosas. Bart ejecuta los lotes. Recibo notificaciones en la UI cuando Bart eleva una decisión. Paso quizá 15 minutos en total respondiendo a tarjetas de decisión a lo largo de la tarde.

Martes por la mañana. Bart reporta la Epic como completada. Hago pull de la rama, levanto en local, reviso contra la especificación, corrijo detalles manuales, escribo pruebas, hago commit.

Resto de la semana. Uso Claude Code para trabajo quirúrgico: el pulido, las pruebas, el UX writing, los bugs puntuales. Cosas que Bart no puede especificar lo suficientemente claro como para ejecutar.

Esto no es “la IA autónoma reemplaza a la ingeniería”. Es “la IA autónoma gestiona el andamiaje, yo me encargo del oficio”. Esa división se siente sostenible de una forma que el loop puro de Ralph nunca lo fue para mí. El loop de Ralph siempre fue una apuesta a todo o nada. Bart mode hace que la autonomía sea parcial, estructurada y — de forma crucial — reversible. Cada lote puede revisarse antes de despachar el siguiente. Cada edición de especificación queda registrada. Cada ticket es reproducible.

Preguntas frecuentes

¿Qué es el modo Bart de Traycer?

El modo Bart de Traycer es un orquestador autónomo de outer-loop que ejecuta Epics de proyectos completos de extremo a extremo, descomponiéndolos en tickets, ejecutando los tickets en lotes paralelos con agentes de codificación IA, verificando contra especificaciones tras cada lote y adaptando el plan en tiempo real cuando la implementación revela desajustes. Funciona dentro del modo Epic de Traycer y es agnóstico al agente: tú eliges el modelo de ejecución (Opus 4.7, GPT-5.4, etc.).

¿En qué se diferencia el modo Bart del ciclo Ralph?

El ciclo Ralph reintenta una tarea a ciegas hasta que la verificación se completa, sin conciencia de por qué ocurrió una falla. El modo Bart es consciente: mantiene una especificación viva, compara la implementación contra la spec después de cada lote, adapta los tickets cuando la realidad se desvía y escala a humanos cuando encuentra un desajuste que no puede resolver. Ralph es un bucle while not done. Bart es un orquestador con memoria.

¿Qué modelos de IA soporta Traycer?

Traycer es agnóstico al agente: no ejecuta su propia inferencia, sino que orquesta cualquier agente de codificación que autentiques. Actualmente incluye integraciones con Claude Code (variantes Opus 4.7 y Sonnet), GPT-5.4, Cursor y Windsurf. Escoges el modelo por Epic según el equilibrio velocidad, coste y calidad que prefieras.

¿Traycer es gratuito?

Sí. Traycer tiene un plan gratuito de $0/mes con capacidad para un slot y una prueba Pro de 7 días. Los planes de pago cuestan $10/mes (Lite), $25/mes (Pro) y $40/mes (Pro+) al momento de esta publicación, con planes anuales 20% más baratos. El plan gratuito es suficiente para probar el modo Bart en un Epic pequeño.

¿Cuándo no debo usar el modo Bart?

Sáltate el modo Bart para ediciones de un solo archivo, investigaciones exploratorias donde aún no conoces el estado final, o bases de código con convenciones implícitas que las especificaciones no capturarían. Claude Code de forma manual es mejor para trabajos quirúrgicos y programación en pareja en tiempo real. El modo Bart destaca cuando un proyecto tiene 5+ tickets con dependencias claras y puede escribirse limpiamente como una especificación.

Trabajemos Juntos

¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudarte.

• Fiverr (desarrollos e integraciones a medida): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (soluciones empresariales): ramlit.com
• ColorPark (diseño & branding): colorpark.io
• xCyberSecurity (servicios de ciberseguridad): xcybersecurity.io