Perdí un domingo entero con una funcionalidad de Laravel que debería haberme llevado cuatro horas.
No porque el código fuera difícil. El código era fácil. Perdí el domingo porque dejé que Claude Code empezara a escribir antes de haber respondido las preguntas que habrían dado forma al diseño. A mitad del segundo prompt me di cuenta de que el agente había asumido una relación uno-a-muchos que necesitaba ser muchos-a-muchos, había generado treinta tests contra el contrato equivocado y ahora refactorizaba con total confianza, hundiéndose cada vez más en la abstracción incorrecta. Para la hora de cenar había revertido la rama a su primer commit y abierto un archivo en blanco.
Ese es el modo de fallo de la ingeniería con agentes de IA que nadie pone en la página de marketing. El agente escribirá con gusto lo que le pidas. No te detendrá cuando pidas algo incorrecto. Y como cada nuevo chat comienza sin memoria del anterior, el mismo error estará esperándote el lunes por la mañana a menos que algo en tu flujo de trabajo obligue a tomar las decisiones antes de que se escriba el código.
Unas semanas después de aquel domingo perdido, vi a un ingeniero llamado John Lindquist recorrer el pipeline exacto que usa para evitar esto, construido alrededor de cinco habilidades con alcance definido que se ejecutan en un orden fijo. Hizo clic. Reconstruí mi propio flujo de trabajo con las mismas cinco habilidades, lo ejecuté en tres proyectos en abril, y la diferencia fue del tipo que me habría hecho reír si alguien me la hubiera descrito hace seis meses. Menos código reescrito. Más funcionalidades entregadas. Menos domingos perdidos.
Este es el pipeline. Cinco habilidades, el orden en que se ejecutan, qué hace cada una realmente bajo el capó, y las partes que no aparecen en las demos.
El modelo mental que cambia cómo usas los agentes
Antes de las habilidades, el modelo mental. Sáltate esto y el resto del artículo serán solo comandos.
El agente no es un ingeniero junior que mejorará en el próximo sprint. El agente es un experto sin memoria — un ingeniero senior sin recuerdos del día anterior, sin conocimiento de tu base de código que no haya sido pegado en la ventana de contexto actual, y sin capacidad de hacer una pregunta de seguimiento dentro de tres días. Cada sesión es el primer día de trabajo.
Esto suena como una desventaja. En realidad es la restricción que hace que el pipeline funcione. Porque el agente no tiene memoria, cada decisión debe hacerse explícita. Cada suposición debe ser expuesta. Cada requisito debe escribirse en algún lugar duradero, en un archivo que la próxima sesión pueda leer. El pipeline que voy a describir es, en el fondo, solo un sistema para producir esos artefactos duraderos en el orden correcto.
Hay una idea más profunda detrás que proviene de The Design of Design de Frederick P. Brooks. Brooks describe la ingeniería como la exploración de un árbol de diseño — cada decisión se ramifica en más decisiones, y realmente no comprendes el diseño hasta que has recorrido las ramas lo suficiente para ver cuáles se cierran y cuáles se abren. La mayoría del software fallido surge de cortar el árbol demasiado pronto. Te comprometiste con una hoja antes de entender el tronco.
Un agente sin memoria cortará el árbol en la primera rama a menos que algo lo fuerce a ir más lejos. Ese algo es la primera habilidad del pipeline.
Habilidad 1: Grill Me — Entrevista a la idea antes de programar
La habilidad Grill Me es lo más contraintuitivo de la lista. Pensarías que el primer paso con un agente de IA es darle un prompt y verlo escribir código. Grill Me hace lo contrario. Le entregas al agente una idea aproximada — tres frases, un párrafo, una solicitud de funcionalidad a medio formar — y él te entrevista a ti.
La entrevista está estructurada alrededor del árbol de diseño de Brooks. El agente identifica cada punto de decisión que tu idea implica pero no resuelve, y te los recorre uno a uno. Para una funcionalidad corta podría hacer dieciséis preguntas. Para algo complejo — un sistema de facturación multi-tenant, un pipeline de contenido con flujos de trabajo ramificados, una nueva superficie de autenticación — lo he visto generar de treinta a cincuenta preguntas antes de estar satisfecho. La mayoría de esas preguntas son las que yo debería haberme hecho a mí mismo y no lo hacía.
Así fue una sesión de Grill Me en un proyecto real el mes pasado. Le dije que quería añadir "espacios de trabajo en equipo" a un panel SaaS. Respondió con:
- ¿El espacio de trabajo pertenece a un solo usuario o a un equipo?
- Si es un equipo, ¿puede un usuario pertenecer a múltiples equipos simultáneamente?
- ¿Los espacios de trabajo heredan permisos de la organización padre o definen los suyos propios?
- ¿Qué sucede con los recursos de un espacio de trabajo cuando su propietario deja la organización?
- ¿La facturación del espacio de trabajo se incluye en la factura de la organización o se factura por separado?
Estaba a punto de escribirle a Claude "añade espacios de trabajo en equipo al panel". Si lo hubiera hecho, el agente habría tomado cinco decisiones ocultas por mí, habría escrito código basado en esas suposiciones, y habría descubierto la discrepancia alrededor de la pregunta 4, en producción, cuando alguien dejara un equipo. La entrevista hizo visibles las suposiciones antes de que existiera una sola línea de código.
El patrón es el mismo siempre. La mayoría de las preguntas parecen obvias en retrospectiva, que es exactamente por lo que vale la pena exponerlas — las preguntas obvias en retrospectiva son las que nos saltamos porque nuestro cerebro nos dice que ya conocemos la respuesta. El agente no tiene ese sesgo. Simplemente recorre el árbol.
Puedes pensar en la salida como una transcripción, pero la transcripción no es el entregable. El entregable es la comprensión compartida — un estado en el que tú y el agente están de acuerdo en cada decisión consecuente que la funcionalidad implica. Una vez que tienes eso, la siguiente habilidad toma el relevo.
Habilidad 2: Escribe un PRD — Fija la comprensión compartida en forma duradera
La salida de la entrevista muere en el momento en que se cierra la ventana del chat. Ese es el impuesto del agente sin memoria que mencioné antes. La habilidad Write a PRD existe para resolver ese problema de un solo golpe: convierte la transcripción de Grill Me en un Documento de Requisitos de Producto, formateado para un lector de IA, y lo envía como un issue al rastreador de tu proyecto — generalmente un issue de GitHub.
Hay tres cosas que notar sobre cómo está estructurada esta habilidad.
Primero, está escrita para el próximo agente, no para ti. Un PRD tradicional se lee como un documento de ventas. Este se lee como una firma de función con prosa. Cada requisito es verificable. Cada restricción es explícita. Cada decisión de diseño de la entrevista está capturada con el razonamiento detrás de ella. La próxima sesión no tendrá acceso a tu recuerdo de por qué elegiste muchos-a-muchos en lugar de uno-a-muchos — pero tendrá acceso al PRD, y el PRD se lo dirá.
Segundo, vive en el rastreador de issues. No en una carpeta docs/, no en Notion, no pegado en un chat. La razón importa: el rastreador de issues es el lugar donde cada otra herramienta — humanos, agentes, CI, habilidades posteriores — buscará la fuente de verdad sobre esta funcionalidad. Poner el PRD en cualquier otro lugar crea una bifurcación en la historia del diseño que te perseguirá en seis semanas.
Tercero, te compromete. Una vez que el PRD está en GitHub, has convertido una conversación en un artefacto. Tu yo futuro puede releerlo. El futuro Claude puede releerlo. Un compañero de equipo que se una al proyecto la semana que viene puede releerlo. La conversación, con sus tangentes ramificadas y pensamientos a medio formar, se fue. Lo que sobrevive es el diseño resuelto.
Solía descartar los PRDs como algo que los product managers escribían para justificar sus salarios. Ver a un agente sin memoria avanzar a toda velocidad por una funcionalidad compleja usando un PRD conciso de una página como su única entrada de contexto cambió esa opinión por completo. El PRD no es burocracia. Es la memoria de trabajo del agente entre sesiones.
Habilidad 3: PRD a Issues — Cortes verticales, no capas horizontales
Aquí es donde la mayoría de los flujos de trabajo con IA se desmoronan. Tienes un PRD. Se lo entregas al agente. El agente decide "implementar la funcionalidad". Cuarenta y cinco minutos después tienes trescientas líneas de abstracción a medio construir y ningún software funcionando.
La solución es la habilidad PRD to Issues, y toma prestado directamente de un patrón que Andy Hunt y Dave Thomas llamaron balas trazadoras en The Pragmatic Programmer. Una bala trazadora es un corte vertical — una implementación delgada de extremo a extremo que toca cada capa del sistema desde la UI hasta la base de datos, hace una sola cosa pequeña de principio a fin, y demuestra que el diseño funciona de extremo a extremo antes de que cualquier capa se construya completamente.
PRD to Issues toma el PRD y lo descompone en cortes verticales, cada uno con el alcance de una sola bala trazadora. Para la funcionalidad de espacios de trabajo en equipo que mencioné antes, la habilidad dividió el PRD en cuatro issues:
- Issue 1 (sin bloqueos): Crear el modelo
workspace, la migración y un solo endpoint que permita a un usuario autenticado crear un espacio de trabajo para sí mismo. UI: un botón. Tests: creación del modelo, el endpoint devuelve 201, el botón envía el payload correcto. - Issue 2 (bloqueado por Issue 1): Añadir multi-membresía — permitir que un usuario pertenezca a múltiples espacios de trabajo, con una tabla intermedia
workspace_usery un selector de espacios de trabajo en la barra de navegación. - Issue 3 (bloqueado por Issue 1, en paralelo con Issue 2): Añadir las reglas de herencia de permisos del PRD. Lógica de dominio pura con su propia suite de tests.
- Issue 4 (bloqueado por Issues 2 y 3): Añadir la lógica de consolidación de facturación y la generación de líneas de factura.
Dos cosas que notar sobre esa descomposición. Primero, el Issue 1 es una funcionalidad completa y funcional por sí misma — si te detuvieras después del Issue 1, tendrías software entregable. Esa es la promesa de la bala trazadora: cada corte es utilizable de extremo a extremo. Segundo, el grafo de bloqueo es explícito. Los Issues 2 y 3 pueden ejecutarse en paralelo, lo que significa que puedo crear dos agentes, uno para cada issue, y trabajarán simultáneamente sin pisarse.
Ese paralelismo es el factor que la mayoría de los equipos aún no han internalizado. Cuando dejas de pensar en los agentes como un solo trabajador y empiezas a pensarlos como un pool de trabajadores con dependencias explícitas, el rendimiento de una sesión de ingeniería cambia de forma. Escribí el modelo mental más amplio para esto en la arquitectura agent-swarm para Claude Code — PRD to Issues es el artefacto concreto que hace que el trabajo estilo enjambre sea seguro en lugar de caótico.
La otra cosa que PRD to Issues previene es el peor modo de fallo de la ingeniería con IA: la trampa del corte horizontal. Sin cortes verticales, un agente tenderá a construir primero todos los modelos, luego todos los controladores, luego todas las vistas, luego todos los tests. A mitad de camino, tu rama tiene una capa de datos completa que nada usa, una UI mockeada contra el contrato equivocado, y cero software funcionando. Con cortes verticales, siempre tienes un sistema funcionando; simplemente tienes un sistema funcionando más pequeño que la funcionalidad final.
Habilidad 4: TDD — Rojo, verde, refactorizar (y por qué el refactorizar duele)
Ahora tienes el PRD, tienes los issues y estás listo para escribir código. Aquí es donde la habilidad TDD toma el control, y donde el pipeline comienza a revelar cómo se comportan realmente los agentes de IA bajo presión.
La habilidad TDD ejecuta el clásico ciclo rojo/verde/refactorizar, pero adaptado para agentes:
- Rojo: El agente escribe un test que falla para el siguiente comportamiento del issue actual. Ejecuta el test. Confirma que falla por la razón correcta. (Este sub-paso importa — los agentes a veces escriben un test que falla por la razón incorrecta, y lo descubrirás dos horas después cuando "pasar" no significa lo que pensabas.)
- Verde: El agente escribe el código mínimo necesario para que el test pase. Ejecuta el test. Confirma que pasa.
- Refactorizar: El agente mejora el código sin cambiar el comportamiento. Ejecuta el test. Confirma que sigue pasando.
Los pasos 1 y 2 funcionan a la perfección con agentes. Claude es excelente escribiendo tests enfocados, igualmente excelente escribiendo implementaciones mínimas para que esos tests pasen. La primera vez que lo vi arrasar con una clase de servicio Laravel en veinte minutos, con cada método cubierto por un test que fue escrito antes de que el método existiera, genuinamente sentí que había estado haciendo mi trabajo mal durante una década.
El paso 3 es donde vive el problema.
Aquí va la parte honesta de todo este artículo. Los agentes de IA son profundamente reacios a refactorizar su propio código dentro del mismo contexto. El patrón es así: escribes un test verde, el agente escribe el código mínimo, le dices que refactorice, y devuelve el mismo código con un comentario que dice "esto ya está bien estructurado". No está mintiendo. Desde su propio contexto, el código se ve bien. El problema es que el agente ha estado mirando su propia lógica durante una hora y ha perdido la perspectiva necesaria para detectar el mal olor.
La solución que me está funcionando — y que la habilidad TDD incorpora — es separar el paso de refactorización en una sesión de agente nueva. Nueva ventana de contexto. Sin historial de haber escrito el código original. Le entregas a la nueva sesión el test que fallaba y luego pasaba junto con la implementación verde, y le pides que refactorice. Sin el sesgo del autor original, está dispuesto a destrozar el código. El test le da un contrato contra el cual refactorizar. La refactorización termina. Haces commit.
Este es el momento que mucha gente pasa por alto cuando dice "la IA realmente no puede hacer TDD". Sí puede — pero solo si tratas cada fase del ciclo rojo/verde/refactorizar como una sesión de agente con alcance separado, no como una sola conversación. La habilidad impone ese alcance. El principio es el mismo que cubrí en por qué la precisión en los prompts supera a la creatividad — el agente es tan bueno como el contexto que le das, y eso incluye el contexto que no le das.
Hay una segunda sutileza que la habilidad TDD maneja. Se niega a dejar que el agente se salte el paso rojo. Si dejas que un agente escriba un test contra código existente, escribirá un test que pasa en la primera ejecución — y no tendrás idea de si el test realmente está ejercitando el comportamiento que te importa. La habilidad bloquea esto imponiendo el estado de fallo primero. No avanzas hasta que el test falle por una razón que puedas articular.
Habilidad 5: Mejorar la arquitectura de la base de código — Cuando el pipeline vuelve al inicio
Las cuatro habilidades anteriores te darán una funcionalidad funcionando. No evitarán, por sí mismas, que tu base de código se deteriore. A lo largo de cinco o diez funcionalidades, acumularás el tipo de deuda estructural que no aparece en ningún PR individual pero que lentamente hace cada funcionalidad futura más difícil de construir. La quinta habilidad es lo que detecta esa deriva.
Improve Codebase Architecture es diferente de las otras. No se ejecuta dentro del pipeline lineal — se ejecuta periódicamente, entre ciclos de funcionalidades, como un pase de limpieza. Su trabajo es examinar la base de código actual y proponer refactorizaciones deliberadas, luego convertir las mejores en nuevos issues que vuelven a entrar al pipeline por arriba.
La forma en que funciona no se parece a nada en el resto del flujo de trabajo. La habilidad genera tres o más sub-agentes en paralelo, cada uno con el prompt de proponer un diseño de interfaz radicalmente diferente para el área de la base de código que se va a refactorizar. Tres sub-agentes porque uno solo confirmaría el statu quo y dos caerían en una dicotomía — tres es el número más pequeño que fuerza la aparición de alternativas genuinas.
Ejecuté esto el mes pasado en un módulo de pipeline de contenido que se había vuelto desordenado. Los tres sub-agentes volvieron con:
- Propuesta A: Un pipeline funcional puro de pasos componibles, cada uno una función pura sobre un payload tipado.
- Propuesta B: Un diseño orientado a eventos con una cola y un conjunto de consumidores independientes.
- Propuesta C: Una jerarquía tradicional de clases de servicio con una clase base y tres estrategias concretas.
El agente padre evaluó las tres contra las restricciones reales de la base de código — cobertura de tests, forma de despliegue, el modelo de datos existente — y recomendó un híbrido de A y B: pasos funcionales puros por dentro, despachados sobre la infraestructura de colas existente. Ninguna de las tres propuestas puras era la respuesta correcta. El híbrido sí lo era. Y nunca habría llegado al híbrido por mi cuenta, porque mi cerebro había estado anclado a la forma existente de clases de servicio durante meses.
La salida de la habilidad es un RFC, también archivado como un issue de GitHub. El RFC describe la refactorización propuesta, las alternativas que fueron consideradas y rechazadas, el razonamiento detrás de la recomendación, y el camino de migración incremental sugerido. Una vez que el RFC es aprobado, vuelve a entrar al pipeline en el paso 1 — haces Grill Me a la propuesta de refactorización, escribes un PRD para ella, la descompones en issues, la desarrollas con TDD.
Ese ciclo es la parte más difícil de comunicar sin verlo funcionar. El pipeline no es realmente lineal. Es un bucle. Las funcionalidades pasan por 1→2→3→4. Los refinamientos periódicos de arquitectura pasan por 5→1→2→3→4. A lo largo de un trimestre, la base de código se compone en una dirección que elegiste en lugar de derivar en una dirección que encontró sola.
La línea temporal — Cómo una funcionalidad real se mueve a través del pipeline
Permíteme recorrer cómo se ve esto realmente en el tiempo, para la funcionalidad de espacios de trabajo en equipo que sigo referenciando, para que la abstracción tenga forma.
Lunes por la mañana, 45 minutos. Ejecuto Grill Me sobre la idea aproximada. Veintidós preguntas. Las respondo. Al final de la sesión, el árbol de diseño se ha recorrido lo suficiente como para que pueda describir la funcionalidad en un solo párrafo sin ambigüedades.
Lunes por la mañana, 20 minutos. Ejecuto Write a PRD. La habilidad genera el documento a partir de la transcripción de la entrevista, lo reviso, edito dos frases y lo envío como un issue de GitHub. Issue #341.
Lunes por la mañana, 15 minutos. Ejecuto PRD to Issues. Descompone el #341 en los cuatro sub-issues que describí arriba, con el grafo de bloqueo adjunto. Issues #342, #343, #344, #345.
Lunes por la tarde hasta el martes. Ejecuto TDD en el issue #342 (el corte fundamental). Unas cuatro horas en total. Rojo, verde, refactorizar en cada comportamiento. Mantengo el paso de refactorización en una ventana de contexto separada. El issue se cierra.
Miércoles. Creo dos sesiones paralelas de TDD, una en el #343 y otra en el #344. Son issues independientes por diseño. Unas tres horas cada una, ejecutándose en ventanas paralelas. Ambos se cierran.
Jueves por la mañana. Ejecuto TDD en el #345, la consolidación de facturación. Unas cinco horas, porque la superficie de tests es más amplia. Se cierra al final del día.
Viernes. Ejecuto Improve Codebase Architecture contra el módulo de espacios de trabajo. Los tres sub-agentes proponen tres estructuras. El padre recomienda una pequeña refactorización para extraer la lógica de verificación de permisos a un módulo puro. RFC archivado como issue #346. Decido que vale la pena, ejecuto el bucle de nuevo y entrego la refactorización el viernes por la tarde.
Total transcurrido: unas treinta horas de trabajo enfocado a lo largo de cinco días, para una funcionalidad que habría estimado en dos semanas antes de empezar a ejecutar este pipeline. La razón por la que se comprimió no es que los agentes sean más rápidos que yo tecleando. Lo son — pero teclear nunca fue el cuello de botella. La razón es que el pipeline eliminó casi todos los ciclos de retrabajo que solían devorar los tres días de en medio de la semana.
La parte honesta — Dónde este pipeline falla
He estado contándote qué funciona. El artículo no gana tu confianza a menos que también te diga dónde se rompe.
El pipeline asume que puedes escribir buenas respuestas durante Grill Me. Si no puedes articular lo que realmente quieres, las preguntas solo exponen la brecha. La habilidad no es un sustituto del pensamiento — es una función forzadora del pensamiento. He visto desarrolladores intentar usar Grill Me como una forma de "descubrir qué quieren" a mitad de sesión, y el resultado es una transcripción llena de "no sé, ¿tú qué piensas?" lo cual produce un PRD que es efectivamente las preferencias del agente, disfrazadas como las del usuario. Ese PRD será entonces el contrato que cada agente posterior cumplirá, y descubrirás en el issue #4 que las preferencias del agente no eran las tuyas.
El problema de refactorización del TDD no se resuelve completamente, ni siquiera con una sesión nueva. A veces el nuevo agente mirará el código y producirá una limpieza marginal que omite el problema estructural más profundo. El patrón al que he llegado: ejecuto la refactorización dos veces, en dos sesiones frescas separadas, y miro ambas. Si coinciden, hago commit. Si discrepan, la discrepancia suele ser donde vive la refactorización real, y elegiré la mejor de las dos o entregaré ambas a un tercer agente para reconciliar. Esto es más lento de lo que me gustaría.
Los issues paralelos no son realmente gratis. Cuando ejecuto dos sesiones TDD en paralelo sobre issues independientes, estoy dividiendo mi propia atención — y ese es el costo real, no el cómputo del agente. El grafo de bloqueo en PRD to Issues evita que los agentes interfieran entre sí en el código, pero no puede evitar que yo haga mal el cambio de contexto. Me limito a dos sesiones paralelas por esa razón. Tres me quiebran.
La habilidad de arquitectura puede sobre-refactorizar. La primera vez que ejecuté Improve Codebase Architecture contra un módulo saludable, generó tres propuestas serias de refactorización para código que no necesitaba refactorizarse. La habilidad tiene sesgo hacia encontrar trabajo. Tú eres el freno. Si ninguna de las tres propuestas mejora materialmente la base de código, la respuesta correcta es saltarse la refactorización y re-ejecutar la habilidad en dos meses. La disciplina importa más aquí que en cualquier otro paso.
La longitud de la habilidad no es calidad de la habilidad. Las dos mejores habilidades de este pipeline — Grill Me y PRD to Issues — son cortas. Quizás cien líneas cada una. Los escritores de habilidades que he visto producir los peores resultados son los que tratan la longitud de la habilidad como indicador de meticulosidad. La precisión en cuándo una habilidad se activa y qué produce importa mucho más que cuánto texto de instrucción contiene. Cubrí este patrón en cómo las habilidades de Claude realmente ejecutan un flujo de trabajo — el mismo principio aplica aquí, duplicado.
Cómo esto transforma lo que un ingeniero hace todo el día
Aléjate de las cinco habilidades por un momento. La forma de trabajo que produce el pipeline es genuinamente diferente de lo que hacía en 2024, y vale la pena decir en voz alta qué cambió.
Escribo menos código. Escribo más contratos. El PRD es un contrato. Los issues son contratos. Los tests son contratos. Los RFCs son contratos. La implementación real es cada vez más algo que un agente produce contra un contrato que yo redacté, y mi tiempo invertido por funcionalidad se ha desplazado fuertemente hacia el extremo de escritura de contratos.
Pienso más en árboles de decisión, menos en sintaxis. Las tres primeras habilidades del pipeline tratan de resolver el árbol de diseño antes de que exista cualquier código. Las dos posteriores tratan de ejecutar limpiamente contra el árbol resuelto. Una vez que noté ese patrón, mis hábitos de ingeniería fuera del pipeline también empezaron a cambiar — me sorprendo a mí mismo, a mitad de una conversación sobre una funcionalidad, haciendo el tipo de preguntas que Grill Me hace, antes de que cualquier herramienta se ejecute.
Confío en el paralelismo de una forma que nunca hacía antes. Dos sesiones TDD simultáneas en issues independientes suena como un truco de productividad. En realidad es un modo diferente de ingeniería. La habilidad mental que requiere es la capacidad de diseñar el grafo de bloqueo correctamente aguas arriba — si descompones mal los issues, las sesiones paralelas colisionan. Si los descompones bien, el paralelismo es casi gratis. El pipeline castiga la mala descomposición y recompensa la buena, lo cual es un bucle de retroalimentación que nunca había tenido antes.
Trato la memoria como un artefacto, no como una suposición. Cada decisión importante vive en un lugar que el futuro Claude puede leer. El PRD, los issues, los nombres de los tests, los mensajes de commit, los RFCs — todo está estructurado como si un ingeniero senior sin memoria pudiera aterrizar en el repositorio mañana sin contexto, porque en la práctica, eso es exactamente lo que sucede cada vez que abro una nueva sesión de agente.
Si quieres una mirada más profunda a cómo el sistema de habilidades subyacente permite este tipo de composición, la guía de arquitectura de habilidades de agente es el post al que te dirigiría a continuación. El pipeline que describo aquí es cómo se ven las habilidades cuando las conectas con intención.
El curso que realmente estoy viendo
Sería deshonesto si no mencionara dónde surgieron la mayoría de estos patrones para mí. Matt Pocock — el ingeniero detrás de gran parte de la educación sobre TypeScript en la que me he apoyado silenciosamente durante años — impartió una cohorte de dos semanas llamada Claude Code for Real Engineers del 30 de marzo al 13 de abril de 2026, y el currículo se mapea casi exactamente al pipeline que acabo de describir. Protocolo Plan/Execute/Clear. Implementación de balas trazadoras. Escritura de PRDs para lectores de IA. El patrón de bucle autónomo al final de la segunda semana.
El curso cuesta $795 en AI Hero. No estoy afiliado, no recibo comisión, y no me he inscrito en la cohorte en vivo — la versión bajo demanda es lo que está disponible ahora, y estoy evaluando si la estructura justifica el costo dado que la mayoría de los patrones son públicos y reproducibles si estás dispuesto a ensamblarlos. La opinión honesta: si quieres comprimir la curva de aprendizaje de meses a semanas y prefieres no armar el pipeline de cinco habilidades a partir de artículos de blog como este, la cohorte es una apuesta razonable. Si eres paciente y el pipeline de arriba te da suficiente para empezar, probablemente puedas llegar por tu cuenta.
Lo que sí diré es que la categoría que ocupa este curso — práctica estructurada de ingeniería alrededor de agentes de IA, en oposición a contenido de "tips y trucos" — es la que más importará en los próximos dos años. El mercado se va a bifurcar en ingenieros que tratan la IA como un acelerador de tecleo e ingenieros que la tratan como un colaborador sin memoria que necesita un pipeline real. El segundo grupo va a dar vueltas alrededor del primero.
Más allá de las cinco habilidades — Hacia dónde estoy avanzando
El pipeline tal como está es sólido. No es donde quiero que termine.
Lo que estoy experimentando ahora es la integración autónoma de agentes en los bordes. Específicamente: un agente programado que re-ejecuta Improve Codebase Architecture contra el repositorio cada dos semanas, archiva RFCs como issues, y me etiqueta para revisión. No tengo que acordarme de ejecutar la habilidad. La habilidad se ejecuta sola. Los RFCs llegan a mi cola. Yo los apruebo y vuelvo a entrar al pipeline, o los cierro como wontfix. El problema de la deriva arquitectónica se convierte en un checkbox pasivo en lugar de un hábito activo.
La otra pieza es la disciplina de la ventana de contexto a lo largo del pipeline. Cada paso produce un artefacto que se convierte en el contexto de entrada para el siguiente paso. Si el artefacto es demasiado verboso, el contexto del siguiente paso se llena y el agente se vuelve menos inteligente. El arte está en hacer cada artefacto tan conciso como sea posible mientras siga siendo un contrato completo. He estado recortando mi plantilla de PRD durante el último mes, y la calidad del código downstream ha mejorado mediblemente cada vez que corté un párrafo que no estaba aportando. Ese principio — la idea de que menos contexto elegido con precisión supera a más contexto curado vagamente — es la palanca más grande en la ingeniería con agentes de IA de la que nadie habla en los tutoriales.
La tercera pieza es la aplicación agnóstica al lenguaje. He estado ejecutando este pipeline contra Laravel, contra Next.js, contra un pipeline de datos en Python, y contra un repositorio de infraestructura pesado en Bash. Funciona en los cuatro. Las habilidades no saben en qué lenguaje están operando; operan sobre el árbol de diseño, el PRD, los issues, los tests y los patrones arquitectónicos. Ese agnosticismo respecto al lenguaje es la propiedad que me hace pensar que este pipeline es el correcto para invertir en los próximos dos años, independientemente del stack en el que acabe trabajando.
Qué hacer antes del lunes por la mañana
Si has leído hasta aquí y estás convencido de la idea, este es el orden en que sugeriría que lo pruebes. No instales las cinco habilidades a la vez. El pipeline es secuencial por una razón, y tratar de adoptarlo como un Big Bang abrumará cualquier flujo de trabajo que tengas actualmente.
- Esta semana: Instala Grill Me. Úsalo en la próxima funcionalidad que de otro modo simplemente le pedirías a Claude que escribiera. Observa las preguntas que hace. Observa cuáles no podrías haber respondido sin él. Ese es el valor.
- La próxima semana: Añade Write a PRD. Pasa la salida de Grill Me a través de ella. Archiva el PRD como un issue de GitHub. Acostúmbrate a que el artefacto viva en un lugar duradero.
- La semana siguiente: Añade PRD to Issues. Observa cómo tus funcionalidades se descomponen en balas trazadoras. Aprende a distinguir buenos cortes verticales de malos — los malos regresan como un solo issue que no se cierra.
- Semana cuatro: Añade TDD. Prepárate para la fricción del paso de refactorización. Resuélvelo ejecutando la refactorización en una sesión separada.
- Semana seis: Añade Improve Codebase Architecture. Ejecútalo una vez. Ve si confías lo suficiente en la salida como para actuar en consecuencia.
Para la semana ocho tendrás un pipeline funcionando. Para la semana doce estarás diseñando tus propias variaciones. Para el mes seis el flujo de trabajo se sentirá tan natural como el que tenías antes de que existieran los agentes, excepto más rápido, más deliberado y más difícil de romper.
El domingo que perdí en Laravel fue el que necesitaba perder. Fue el costo de aprender, en mis huesos, que la ingeniería con agentes de IA no se trata de escribir prompts y ver cómo aparece el código. Se trata de producir los artefactos correctos en el orden correcto para que un experto sin memoria pueda retomar el trabajo en cualquier punto y continuarlo sin perder el diseño. El pipeline es cómo haces eso posible.
No he perdido un domingo así desde entonces.
Preguntas frecuentes
¿Qué significa realmente "ingeniería con agentes de IA" en la práctica?
Ingeniería con agentes de IA significa tratar al agente como un ingeniero senior sin memoria que necesita cada decisión, requisito y restricción capturados como un artefacto duradero antes de que se escriba el código. En la práctica es un pipeline fijo — Grill Me, PRD, Issues, TDD, Refactorización de Arquitectura — donde cada paso produce el contexto del que depende el siguiente paso. Para el recorrido completo, consulta las secciones del pipeline arriba.
¿Estas habilidades solo funcionan en Claude Code?
Las cinco habilidades son agnósticas respecto al lenguaje y al concepto — los patrones subyacentes (árbol de diseño, cortes verticales, rojo/verde/refactorizar, sub-agentes en paralelo) funcionan con cualquier runtime de agentes que soporte habilidades o instrucciones equivalentes con alcance definido. Claude Code es donde las ejecuto porque el sistema de habilidades allí es el más maduro, pero el mismo pipeline puede reproducirse en otros entornos con comandos slash personalizados o system prompts.
¿Por qué los agentes de IA se niegan a refactorizar su propio código?
Los agentes tienen dificultades para refactorizar dentro del mismo contexto porque han estado razonando sobre el código durante toda la sesión y pierden la perspectiva necesaria para detectar los malos olores. La solución es abrir una sesión de agente nueva sin contexto previo, entregarle solo el test que fallaba y luego pasaba junto con la implementación verde, y pedirle que refactorice contra el contrato del test. El principio se cubre en la sección de TDD arriba.
¿Qué es un "corte vertical" o "bala trazadora" en este contexto?
Un corte vertical es una implementación de extremo a extremo que toca cada capa del sistema — UI, API, lógica de dominio, base de datos — pero hace solo una cosa pequeña de principio a fin. Se originó como el patrón de "bala trazadora" en The Pragmatic Programmer y es la unidad de trabajo en la que PRD to Issues descompone una funcionalidad. El resultado es que cada issue que cierras entrega software funcionando, no una capa a medio construir.
¿Vale la pena los $795 del curso Claude Code for Real Engineers?
La cohorte cubre los mismos patrones descritos en este artículo — Plan/Execute/Clear, escritura de PRDs para lectores de IA, implementación de balas trazadoras, bucles autónomos — en un formato estructurado de dos semanas. Vale el costo si quieres comprimir la curva de aprendizaje y prefieres instrucción guiada en lugar de ensamblar el pipeline a partir de fuentes públicas. La versión bajo demanda es lo que está disponible actualmente; las cohortes en vivo se re-ejecutan periódicamente.
Trabajemos juntos
¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudar.
- Fiverr (construcciones personalizadas e integraciones): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (soluciones empresariales): ramlit.com
- ColorPark (diseño y branding): colorpark.io
- xCyberSecurity (servicios de seguridad): xcybersecurity.io
