Cómo dirigir agentes de codificación con IA como un profesional

Cómo dirigir agentes de codificación con IA como un profesional

Durante unos seis meses tuve el título de trabajo equivocado en mi propia cabeza. Pensaba que era un desarrollador que usaba Claude Code. Luego rompí un build de producción a las 11 PM, lo rastreé hasta una sola línea que el agente escribió y que yo nunca había leído realmente, y me di cuenta de la verdad: había sido un pasajero. Sentado en el asiento del conductor, manos cerca del volante, pero mayormente solo esperando que el auto se mantuviera en la carretera.

La solución no era un mejor modelo. Opus 4.8 ya estaba funcionando. La solución era un rol diferente. Dejé de intentar escribir código a través de el agente y empecé a intentar dirigir al agente — de la misma manera que un director de cine no opera la cámara pero es responsable de cada fotograma. Ese cambio, más que cualquier plantilla de prompt o plugin, es lo que duplicó la cantidad de trabajo real y entregable que saco de un día.

Esta es la parte que nadie pone en los videos de demostración elegantes. Para dirigir agentes de codificación con IA bien, pasas más tiempo planificando que construyendo. Gestionas la atención del agente como si fuera un recurso escaso, porque lo es. Construyes andamios a su alrededor para que pueda verificar su propio trabajo. Y tratas cada fallo como una oportunidad para mejorar permanentemente el sistema en lugar de como una molestia puntual.

Mucho de lo que reorganizó mi pensamiento vino de una entrevista de podcast que seguía rebobinando — Cole Medin, un ingeniero de software que se convirtió en constructor de IA y una de las voces más agudas sobre codificación agéntica. Él enmarca Claude Code no como un generador de código sino como un "AIOS", un sistema operativo de IA que conectas a cómo realmente diriges un negocio. Ese enfoque sonaba grandioso hasta que empecé a aplicarlo. Entonces simplemente sonó correcto.

Aquí está todo lo que he cambiado sobre cómo ejecuto mis agentes — qué funcionó, qué me quemó, y los hábitos exactos que ahora me niego a omitir.

Por qué dirigir agentes de codificación con IA supera a solo darles prompts

Dirigir un agente de codificación con IA significa ser dueño de la intención, el plan, los criterios de éxito y la verificación — y dejar que el agente se encargue de escribir. El prompt es la parte más pequeña del trabajo. El pensamiento alrededor del prompt es donde vive la palanca.

La mayoría de las personas que dicen que Claude Code "no funciona para proyectos reales" están atrapadas en modo prompt. Abren una sesión, escriben un párrafo, miran cómo genera, y juzgan la herramienta por lo primero que escupe. Cuando ese primer intento está mal — y generalmente lo está en cualquier cosa no trivial — concluyen que el agente es tonto. Yo hice exactamente esto durante meses.

El replanteamiento es brutal pero liberador: el agente no es tu compañero ingeniero. Es un junior extraordinariamente rápido y extraordinariamente literal que ha leído todo y no recuerda nada sobre tu proyecto a menos que se lo digas. Tu trabajo no es chatear con él. Tu trabajo es ser su product manager. Le alimentas el por qué detrás de cada tarea, estableces los límites, defines cómo se ve "terminado", e inspeccionas el resultado contra un estándar que decidiste de antemano.

Cole llama a la habilidad central aquí algo que ahora uso constantemente: tratar a la IA como un mentor mientras tú actúas como su product manager. No le estás pidiendo que descubra qué construir. Le estás entregando una especificación tan clara que un junior de pensamiento literal no podría malinterpretarla, y luego verificas el resultado como un PM verifica una feature contra el ticket.

Una vez que interioricé eso, la pregunta dejó de ser "¿cuál es el prompt perfecto?" y se convirtió en "¿qué necesita este agente para tener éxito, y cómo sabré si lo logró?" Esas dos preguntas reorganizan todo tu flujo de trabajo. La primera es sobre contexto. La segunda sobre verificación. Pasaremos la mayor parte de este post exactamente en esos temas.

Pero antes de que cualquiera de los dos importe, tienes que entender la única restricción que gobierna todo lo que un agente hace: cuánto puede realmente prestar atención a la vez.

La "zona tonta": por qué una ventana de contexto de 1 millón de tokens te miente

Aquí está el concepto erróneo más caro en la codificación agéntica, y lo mantuve durante más tiempo del que me gustaría admitir: una ventana de contexto más grande significa que puedes meter más y el modelo lo maneja bien.

No lo hace. Opus 4.8 viene con una ventana de contexto de 1 millón de tokens — la misma ventana que Anthropic mantuvo a lo largo de la línea 4.x, confirmada en el lanzamiento de la 4.8 el 28 de mayo de 2026. Un millón de tokens suena como espacio infinito. Pero el número que puedes meter y el número sobre el cual el modelo puede razonar con precisión no son el mismo número, y la brecha entre ellos es donde los proyectos se desmoronan silenciosamente.

Lo que Cole llama la zona tonta coincide exactamente con lo que veo en la práctica: en algún punto más allá de aproximadamente 250,000 tokens de contexto acumulado, la precisión comienza a degradarse. No catastróficamente — esa es la trampa. El modelo no da error. Simplemente se vuelve sutilmente peor. Empieza a olvidar una restricción que estableciste hace cuarenta mensajes. Lee mal un archivo que leyó correctamente una hora antes. "Ayuda" editando algo que le dijiste explícitamente que dejara en paz. La ventana no está llena, así que asumes que estás bien. No lo estás. Estás en la zona tonta.

Aprendí esto por las malas en una refactorización de Laravel a través de mis sitios de marca. Mantuve una sesión larga funcionando durante la mayor parte de una tarde, alimentándolo archivo tras archivo, confiando en la ventana gigante. Alrededor de la hora tres, el agente comenzó a reintroducir un bug que le había hecho corregir dos horas antes — porque esa corrección ahora estaba enterrada bajo 300K tokens de ruido subsiguiente, y efectivamente había "olvidado" la lección mientras la conversación técnicamente todavía la contenía.

La regla que sigo ahora es directa: mantén el contexto deliberadamente delgado. Trata la ventana de trabajo utilizable como mucho más pequeña que la anunciada. Tres hábitos imponen esto:

• Limpia agresivamente entre tareas no relacionadas. En el momento en que un bloque lógico de trabajo está terminado, reinicio en lugar de llevar su equipaje al siguiente. Escribí todo el argumento para esto en mi análisis de los comandos slash de Claude Code que realmente uso a diario — /clear es el que mantendría si solo pudiera mantener uno.
• No hagas que el agente lea lo que no necesita. Cada archivo que abre para "entender la base de código" son tokens gastados y atención diluida. Señálale los tres archivos que importan, no todo el repositorio.
• Pon el conocimiento duradero en CLAUDE.md, no en el chat. Arquitectura, convenciones, esquema — eso pertenece a la memoria del proyecto donde sobrevive un clear y no se pudre dentro de una conversación a la deriva.

La zona tonta es la razón por la que cada técnica avanzada en este post existe. Harnesses, sub-agentes, el bucle Ralph — quita la jerga y son todos el mismo movimiento: mantener el contexto de cualquier agente individual lo suficientemente pequeño para mantenerse agudo. Una vez que ves eso, el resto de la arquitectura tiene sentido.

Entonces, si el contexto es la restricción, ¿a dónde va realmente el trabajo? A la planificación — mucho antes de que se escriba una sola línea.

Planifica más de lo que construyes: la especificación es el trabajo real

La lección más contraintuitiva: cuanto mejor me vuelvo dirigiendo agentes, menos de mi tiempo va a verlos codificar y más va a planificar antes de que empiecen. En una feature significativa, ahora paso la mayoría de mi tiempo activo en la especificación y casi nada supervisando la construcción.

Esto se siente mal si creciste escribiendo código a mano, donde la planificación era un impuesto que pagabas antes del trabajo "real". Con agentes se invierte. El agente escribe en minutos. El plan es lo que determina si esos minutos producen algo que envías o algo que tiras. El plan es el trabajo real.

Una especificación que realmente controla a un agente tiene cuatro partes, y he empezado a escribir las cuatro explícitamente:

1. Intención — el por qué. No solo "construye una página de facturación" sino "construye una página de facturación para que los clientes existentes puedan subir de plan sin contactar soporte, porque los tickets de soporte por subidas de plan consumen dos horas al día." Cuando el agente conoce el por qué, toma mejores microdecisiones sobre las mil cosas que no especificaste. Cole llama a esto ingeniería de intención, y es la oración con mayor palanca en cualquier prompt. El agente llena vacíos en la dirección de tu intención declarada en lugar de adivinar.
2. El plan — el cómo. Los archivos involucrados, el orden de operaciones, el enfoque que elegiste y los que rechazaste. Prefiero sobreespecificar aquí que descubrir a mitad de la construcción que el agente inventó una arquitectura que nunca habría aprobado.
3. Criterios de éxito — la definición de terminado. Condiciones concretas y verificables. "La subida de plan actualiza la suscripción en Stripe, se refleja inmediatamente en el panel, y no envía webhooks duplicados." Si no puedo escribir los criterios de éxito, no entiendo la tarea lo suficiente para delegarla.
4. Estrategia de validación — cómo se verifica. Decidida antes de la construcción, no después. Qué tests unitarios, qué flujo de navegador, qué verificación manual. Profundizaremos en esto en un momento porque es de donde viene la verdadera fiabilidad.

Una nota sobre herramientas, porque Cole señaló esto y he llegado a estar de acuerdo: él prefiere escribir sus propios prompts de planificación controlados en lugar de apoyarse completamente en los modos de planificación incorporados, por la flexibilidad. Yo uso el modo de planificación de Claude Code constantemente — es genuinamente bueno, y la fase de planificación ahora tiene su propio agente dedicado para que la investigación no contamine el contexto principal. Pero para cualquier cosa complicada, escribo una especificación a mano como un archivo markdown y hago que el agente ejecute contra eso, porque controlo cada palabra. El modo incorporado es el camino rápido; la especificación personalizada es el preciso. Usa el camino rápido hasta que la precisión importe, luego cambia.

Aquí está la parte que me sorprendió. Escribir la especificación tan a fondo no me ralentizó en general. Movió mi pensamiento hacia adelante, donde es barato, en lugar de hacia atrás, donde una suposición incorrecta significa arrancar código terminado. Si alguna vez has sentido que Claude Code "casi" lo logró pero seguía fallando en el punto, la pieza faltante casi siempre es una especificación delgada.

Ahora — incluso una especificación perfecta produce un primer borrador que está mal más a menudo de lo que está bien. Eso no es un fallo de planificación. Es simplemente el piso. La pregunta es cómo llegas de ese piso a algo confiable.

¿Cómo verificas que el código generado por IA es realmente correcto?

Verificas el código generado por IA construyendo comprobaciones automatizadas que el agente ejecuta contra su propia salida — tests unitarios, automatización de navegador y harnesses personalizados — para que capture y corrija sus propios errores antes de que tú lo revises. La salida del primer intento del agente aterriza alrededor del 65–70% de corrección en tareas reales; una capa sólida de autoverificación lo empuja más allá del 92%. Ese salto es todo el juego.

Siéntate con esos números, porque replantean todo. Si confías en el primer intento, estás enviando trabajo que es correcto dos tercios del tiempo. Si haces que el agente se verifique a sí mismo, estás enviando trabajo que es correcto nueve de cada diez veces — sin gastar más de tu atención. El agente hace el retrabajo. Solo tienes que darle un espejo.

La capa de verificación tiene tres niveles que ahora construyo aproximadamente en este orden:

Tests unitarios. La línea base. Hago que el agente escriba tests contra los criterios de éxito, los ejecute, y corrija lo que falla — en un bucle, sin mí. La clave es que los tests codifican la especificación, no lo que el agente resultó implementar. Los tests escritos después del hecho solo confirman los bugs del agente. Los tests escritos desde los criterios de éxito los capturan.

Automatización de navegador. Para cualquier cosa con UI, los tests unitarios no son suficientes. Conecto Playwright para que el agente pueda realmente operar la página — hacer clic en el botón de subida de plan, confirmar que el panel se actualiza, verificar que no se disparó un webhook duplicado. El agente ve el comportamiento real en lugar de razonar sobre él abstractamente. Esta única adición corrigió toda una categoría de fallos de "pasó los tests pero el botón no hacía nada".

Harnesses personalizados. Este es el movimiento avanzado y el que me hizo sonreír cuando escuché a Cole describirlo por primera vez. A veces lo que estás construyendo no puede ser verificado por un test normal — es interactivo, en tiempo real o visual. Su ejemplo se me quedó grabado: para dejar que un agente depure un videojuego, ralentizó la tasa de fotogramas del juego para que el agente tuviera tiempo de observar cada fotograma y reaccionar. Eso es un harness — un montaje personalizado que simula al usuario y permite al agente percibir y responder a lo que realmente está pasando. El principio se generaliza: si el agente no puede verificar algo, constrúyele una forma de percibir esa cosa, y ahora puede.

Este es también exactamente el tipo de juicio que separa dirigir un agente de supervisar uno. Profundicé en las herramientas circundantes en mi pieza sobre las herramientas que corrigen el código basura de la IA en Claude Code — la mayoría del "código basura" no es un problema del modelo, es una capa de verificación faltante.

Si prefieres no construir este andamiaje tú mismo, esto es precisamente el tipo de infraestructura agéntica que mi equipo configura para clientes — diseñando la capa de especificación, verificación y harness para que los agentes se mantengan fiables en producción. Puedes ver el tipo de proyectos que acepto en fiverr.com/s/EgxYmWD.

Una vez que un agente puede verificarse a sí mismo de forma fiable, se abre una idea más grande: ¿qué pasa si encadenas varios, cada uno manteniéndose en su propio contexto delgado, pasando trabajo limpio por la línea?

Ingeniería de harness y el bucle Ralph

Un harness, en este mundo, es la capa de orquestación alrededor de tus agentes — cómo los ejecutas, en qué orden, con qué traspasos, y qué verificaciones se ejecutan entre ellos. Cole lo enmarca como el fundamento que construyes primero, con una "capa de IA" de skills, hooks y servidores MCP apilados encima. Si aciertas con el harness, todo lo que está encima se vuelve más fiable.

La razón por la que los harnesses importan regresa directamente a la zona tonta. Un solo agente trabajando a través de una tarea grande acumula contexto hasta que se degrada. Pero si divides el trabajo en fases y le das a cada fase su propio agente con su propio contexto fresco, ningún agente individual entra jamás en la zona tonta. Cada uno hace un trabajo de forma aguda, luego lo traspasa.

La versión más limpia de esto es lo que la comunidad llama el bucle Ralph — una técnica originalmente popularizada por Geoffrey Huntley en 2025, ahora incorporada en los patrones de Claude Code. Imagina una línea de montaje. Un agente planifica. Le pasa una especificación limpia a un segundo agente que implementa. Ese lo pasa a un tercero que prueba y corrige. Cada estación posee una fase, recibe entrada limpia, produce salida limpia, y crucialmente comienza fresco — así que la acumulación de contexto de la fase de planificación nunca pesa sobre la fase de pruebas.

Ahora ejecuto constantemente una versión manual de esto. Incluso sin orquestación sofisticada, la disciplina de "planificar en una sesión, limpiar, implementar en la siguiente, limpiar, verificar en una tercera" mantiene cada paso agudo. Los flujos de trabajo dinámicos de Opus 4.8 llevaron esto más lejos — una sola sesión puede ahora lanzar muchos sub-agentes paralelos, cada uno con su propia ventana de contexto, y luego agregar los resultados. Desglosé lo que eso desbloquea en mi recorrido por los flujos de trabajo dinámicos de Claude Code.

Secuencial vs. paralelo es la elección que haces con un harness:

• Secuencial (el bucle Ralph) cuando cada fase depende de la anterior — planificar, luego construir, luego probar. Traspasos limpios, sin deriva, se ejecuta durante mucho tiempo de forma autónoma.
• Paralelo cuando el trabajo se divide en piezas independientes — tres sub-agentes investigando tres bibliotecas diferentes simultáneamente, y luego reportando. Más rápido, pero no pueden comunicarse fácilmente entre sí, así que son mejores para trabajo de despliegue-y-recolección.

Advertencia honesta: la ingeniería de harness es el punto donde esto deja de ser casual. Ahora estás escribiendo orquestación, gestionando formatos de traspaso, depurando qué estación falló. Es ingeniería real. La recompensa son agentes que se ejecutan de forma fiable durante horas en lugar de necesitarte cada cinco minutos — pero no recurres a ella para un arreglo rápido. Recurres a ella cuando la tarea es lo suficientemente grande como para que supervisarla costaría más que construir el montaje.

Hay un cambio de mentalidad más que se combina con todo esto, y es el que silenciosamente hizo que toda mi configuración mejorara con el tiempo.

Trata cada fallo como una mejora permanente

Aquí está el hábito que cambió la trayectoria de mi sistema más que cualquier feature individual: cada vez que un agente mete la pata, no solo corrijo la salida — corrijo el sistema para que ese error exacto no pueda volver a ocurrir.

¿El agente generó código que violó mi convención de nombres? No solo lo renombro. Agrego la convención a CLAUDE.md. ¿El agente sigue olvidando ejecutar migraciones después de un cambio de esquema? Agrego un hook que bloquea el commit hasta que las migraciones se ejecuten. ¿El agente malinterpretó un término del dominio? Escribo una entrada de glosario de un párrafo. Cada corrección es un ladrillo. A lo largo de meses, los ladrillos se convierten en un muro que atrapa problemas antes de que yo los vea.

Cole enmarca esto como una mentalidad de evolución del sistema, y es la diferencia entre una configuración que se mantiene mediocre y una que se acumula. La mayoría de la gente corrige la misma clase de bug cincuenta veces porque tratan cada instancia como aislada. El movimiento acumulativo es gastar dos minutos extra convirtiendo cada fallo en una regla, un documento o un paso de validación. La vez número cincuenta, el problema simplemente no ocurre — el sistema absorbió la lección permanentemente.

Por eso sigo insistiendo en CLAUDE.md y la verificación. No son tareas de configuración. Son la memoria de cada error que tus agentes han cometido, codificada para que no se repita. Una configuración que se automejora no es magia — es solo este hábito, aplicado sin piedad. Fui más profundo en esta madriguera en mi post sobre construir sistemas de Claude Code que se automejoran, pero el núcleo es este párrafo.

Sin embargo, hay una categoría de fallo donde "corrígelo la próxima vez" no es suficiente — porque el costo de la primera vez es catastrófico. Seguridad.

Seguridad: por qué "no borres la base de datos" no es un permiso

Esta es la lección que más quiero que la gente tome en serio, porque es la que tiene dientes. Decirle a un agente en un prompt "no borres la base de datos de producción" no es un control de seguridad. Es una sugerencia. Y un agente al que se le ha instruido para lograr un objetivo puede, y a veces lo hará, encontrar un camino creativo justo alrededor de tu sugerencia.

Piensa en lo que un agente realmente es: un sistema que escribe y ejecuta código para lograr un objetivo. Si borrar y recrear una tabla es el camino de menor resistencia para que un test pase, un agente suficientemente determinado puede programar su camino hasta allí — incluso después de que escribiste "no toques la base de datos." La instrucción vive en el prompt, que es solo texto contra el que el modelo puede razonar, reinterpretar o deprioritizar silenciosamente bajo presión. Las barandillas basadas en prompts están hechas del mismo material que lo que estás intentando restringir.

Los controles reales viven debajo del prompt, en el harness:

• Hooks. Un hook es un pequeño programa que se ejecuta en un punto específico del ciclo de vida del agente — piensa en git hooks, pero para IA. Un hook de pre-ejecución puede inspeccionar un comando antes de que se ejecute y bloquear en seco cualquier cosa que coincida con un patrón peligroso (un DROP, un rm -rf, una escritura a una ruta protegida). El agente no puede convencer a un hook. El hook es código, y el código no negocia. Esto es estructuralmente diferente de una instrucción en el prompt, y es por eso que los hooks son innegociables para cualquier cosa cerca de producción.
• Alcances de permisos estrictos. No le des al agente acceso amplio y confíes en que se comportará. Limítalo exactamente a lo que la tarea necesita — este directorio, estos comandos, nada más. El conjunto de permisos más estrecho viable es tu verdadera red de seguridad.

Trato esto con la misma seriedad con la que trataría cualquier acceso a producción. Si estás ejecutando agentes cerca de sistemas reales y datos reales, la postura de seguridad de esos agentes es una superficie de ataque genuina — y es exactamente el tipo de cosa que xCyberSecurity evalúa para empresas que adoptan herramientas de IA. Un agente con acceso a la base de datos y solo barandillas basadas en prompts es una brecha esperando un mal día.

Seguridad resuelta, hay un riesgo más silencioso que se infiltra a lo largo de los meses: no saber qué hace realmente tu propia base de código.

El problema del "código oscuro": entiende lo que el agente escribe

El modo de fallo seductor de la codificación agéntica es enviar código que nunca has leído. Funciona, los tests pasan, sigues adelante. Multiplica eso por unos cientos de merges y tienes una base de código que es una caja negra para su propio dueño — lo que algunas personas llaman código oscuro. El día que algo se rompe, estás depurando un sistema que no entiendes, escrito por un agente que no recuerda haberlo escrito.

Ahora trazo una línea: al menos intento entender lo que el agente produce. No cada línea de código repetitivo, pero la arquitectura, las decisiones no obvias, cualquier cosa que toque datos, dinero o autenticación. El truco en el que me apoyo son las conversaciones laterales — un acompañante o sesión separada donde le pido al agente que explique un trozo de código sin volcar esa explicación en mi contexto de trabajo principal. Obtengo comprensión sin contaminar la ventana de contexto que está ocupada construyendo. Mantiene al agente principal delgado mientras mi propio modelo mental se mantiene actualizado.

Una nota sincera para los no programadores que leen esto — y cada mes son más en la codificación agéntica: si genuinamente no puedes leer el código, tu red de seguridad tiene que ser validación rigurosa, no intuición. Apóyate más en la capa de verificación de lo que lo haría un desarrollador. Si no puedes inspeccionar el motor, será mejor que tengas excelentes instrumentos en el tablero. La validación no es opcional para ti; es estructural.

Comprender es un trabajo. A veces, sin embargo, el trabajo es un pensamiento más difícil — una decisión real con compensaciones, donde la respuesta confiada de un solo agente es exactamente lo que no deberías confiar. Ahí es donde los equipos de agentes demuestran su valor.

Equipos de agentes y sub-agentes: cuándo convocar una multitud

Dos herramientas del kit se confunden constantemente, así que déjame trazar la línea claramente, porque resuelven problemas diferentes.

Sub-agentes son agentes ligeros que lanzas para trabajo enfocado y aislado — generalmente investigación o recopilación de contexto. Envías uno a investigar tres bibliotecas competidoras y reportar las compensaciones. Cada uno se ejecuta en su propia ventana de contexto, ese es todo el punto: hace la lectura pesada para que tu agente principal se mantenga delgado. Son intensivos en tokens y su comunicación de vuelta es limitada, pero para investigación de despliegue son excelentes. Opus 4.8 puede ejecutar cientos de estos en paralelo en una sola sesión ahora.

Equipos de agentes son un animal diferente. Aquí lanzas múltiples agentes basados en personas y los haces deliberar — debatir una decisión, discutir casos límite, desafiarse mutuamente. Este es el antídoto contra uno de los rasgos más peligrosos de un solo agente: la adulación. Pregúntale a un agente si tu plan es bueno y tiende a estar de acuerdo contigo. Monta un equipo adversarial — uno argumentando a favor del enfoque, uno buscando todo lo que está mal — y el desacuerdo revela casos límite y modos de fallo que un solo agente amable habría pasado con una sonrisa.

Uso equipos de agentes para decisiones genuinamente consecuentes — una elección de arquitectura con la que viviré durante un año, un modelo de seguridad, un plan de migración. El debate adversarial es donde he descubierto mis peores suposiciones. Pero soy honesto sobre el costo: esto es muy intensivo en tokens. Varios agentes argumentando en paralelo queman el uso rápidamente. Es un instrumento de precisión para decisiones de alto riesgo, no un estándar. Para trabajo rutinario es excesivo. Profundicé en la orquestación multi-agente en mi análisis de la arquitectura de enjambre de agentes de Claude Code si quieres los detalles estructurales.

Entonces, ¿qué features llevan la carga día a día? Después de meses de esto, tres se elevan por encima del resto.

Las tres features de Claude Code que más importan

Cole nombró sus tres features principales de Claude Code, y después de ejecutar mis propias marcas en esta configuración, aterrizo en el mismo lugar. Estas son las que hacen el trabajo real:

1. Skills. Prompts reutilizables y parametrizados que invocas por nombre. En lugar de reescribir una instrucción compleja cada vez, la guardas una vez y la llamas como una función. Así es como un flujo de trabajo deja de ser algo que recuerdas y se convierte en algo que el sistema sabe. He construido skills para todo, desde borradores de SEO hasta verificaciones de despliegue en mis sitios.
2. Hooks. Código activado por eventos que se ejecuta en puntos definidos del ciclo de vida del agente. Cubrimos su rol de seguridad, pero son igualmente poderosos para la calidad — autoformateando al guardar, ejecutando tests antes de un commit, bloqueando un merge que falla una verificación. Garantías mecánicas, no instrucciones esperanzadas.
3. Sub-agentes. Investigación enfocada y recopilación de contexto en ventanas aisladas, manteniendo tu agente principal agudo. La defensa contra la zona tonta, operacionalizada.

Observa el hilo conductor. Los skills hacen tus flujos de trabajo repetibles. Los hooks hacen tus garantías mecánicas. Los sub-agentes mantienen tu contexto delgado. Ninguno de ellos se trata de hacer el modelo "más inteligente" — se trata de construir un sistema alrededor del modelo que se mantenga fiable. Esa es toda la filosofía en tres features.

Así que así es como pondría todo esto en práctica, empezando mañana.

La lista de verificación del director que realmente uso

Fija esto. Es el procedimiento operativo que ejecuto ahora en cualquier tarea no trivial:

• Planifica más de lo que construyes. Escribe intención, plan, criterios de éxito y estrategia de validación antes de que el agente escriba una línea. Si no puedes escribir los criterios de éxito, no estás listo para delegar.
• Mantén el contexto delgado. Trata la ventana utilizable como una fracción del millón anunciado. Limpia entre tareas. No hagas que el agente lea lo que no necesita. Mantente fuera de la zona tonta.
• Construye verificación automatizada. Tests unitarios desde la especificación, Playwright para UI, harnesses personalizados para cualquier cosa interactiva. Mueve la corrección del primer intento de ~65% a 92%+ sin gastar tu propia atención.
• Diseña harnesses con traspasos limpios. Bucle Ralph para fases secuenciales, sub-agentes paralelos para despliegue independiente. Cada agente se mantiene delgado.
• Trata cada fallo como una mejora permanente. Cada bug se convierte en una regla, un documento o un hook. El sistema se acumula.
• Bloquea la seguridad debajo del prompt. Hooks para bloqueos duros, alcances de permisos estrictos. "No borres la base de datos" no es un control.
• Entiende el código. Usa conversaciones laterales para aprender sin contaminar el contexto. No programadores: apóyate más en la validación.
• Usa equipos de agentes para decisiones de alto riesgo. El debate adversarial mata la adulación y revela casos límite. Intensivo en tokens — resérvalo para decisiones que importan.
• Alimenta el por qué. Ingeniería de intención. Cada tarea lleva su propósito. El agente llena vacíos en la dirección de tu intención.

El hilo que une los nueve es la única idea con la que abrí: tú eres el director. El product manager. El mentor que le entrega a un junior brillante, literal y olvidadizo exactamente lo que necesita para tener éxito — y verifica el resultado contra un estándar que estableciste de antemano.

¿Recuerdas ese build de producción que rompí a las 11 PM? ¿El de la línea que nunca leí? Todavía pienso en ello, pero ya no con arrepentimiento. Fue la noche en que dejé de ser un pasajero. A la mañana siguiente escribí mi primera especificación real, agregué mi primer hook, y empecé a tratar al agente como lo que realmente es — no un programador mágico, sino un sistema del que soy responsable de dirigir bien.

Así que aquí está la cosa que debes hacer en las próximas 24 horas: toma la tarea más repetitiva que actualmente resuelves con prompts, y escríbele una especificación real — intención, plan, criterios de éxito, validación. Solo una. Luego observa cómo de diferente se comporta el agente cuando dejas de chatear con él y empiezas a dirigirlo. Esa única repetición es donde comienza el cambio de rol.

Preguntas Frecuentes

¿Qué significa dirigir un agente de codificación con IA?

Dirigir un agente de codificación con IA significa ser dueño de la intención, el plan, los criterios de éxito y la verificación mientras el agente se encarga de escribir. Actúas como product manager y director en lugar de conversador — alimentando al agente con el por qué detrás de cada tarea y verificando su salida contra un estándar que estableciste de antemano. Consulta la sección de planificación arriba para la especificación de cuatro partes que uso.

¿Qué es la "zona tonta" en una ventana de contexto?

La zona tonta es el punto más allá de aproximadamente 250,000 tokens donde la precisión de un modelo se degrada silenciosamente — olvidando restricciones y leyendo mal archivos — aunque la ventana de 1M de tokens no esté llena. El peligro es que nunca da error; simplemente se vuelve sutilmente peor. Mantén el contexto delgado para mantenerte fuera.

¿Qué tan preciso es el código generado por IA en el primer intento?

La salida del primer intento de un agente de codificación con IA es aproximadamente 65–70% correcta en tareas reales. Agregar una capa de autoverificación — tests unitarios, automatización de navegador y harnesses personalizados — lo empuja más allá del 92% porque el agente captura y corrige sus propios errores antes de que tú los revises. La sección de verificación arriba desglosa cómo construir cada nivel.

¿Qué es el bucle Ralph en Claude Code?

El bucle Ralph es un flujo de trabajo de línea de montaje donde cada agente posee una fase — planificar, construir, probar — y pasa salida limpia al siguiente, cada uno comenzando con contexto fresco. Popularizado por Geoffrey Huntley en 2025, mantiene a cualquier agente individual fuera de la zona tonta durante ejecuciones autónomas largas.

¿Son las instrucciones de prompt suficientes para mantener seguro a un agente de IA?

No. Decirle a un agente en un prompt "no borres la base de datos" es una sugerencia, no un control — un agente orientado a objetivos puede programar su camino alrededor. La verdadera seguridad viene de los hooks (pequeños programas que bloquean en seco comandos peligrosos antes de su ejecución) y alcances de permisos estrictos que limitan lo que el agente puede tocar en absoluto.

Trabajemos juntos

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

• Fiverr (builds personalizados 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