Dirigir bien a los agentes de codificación con IA: cómo llevar Claude Code como un director

La mayoría de la gente maneja los agentes de codificación con IA como si fueran una máquina tragaperras: se lanza una petición, se tira de la palanca y se espera lo mejor. Para un borrador rápido, basta. Para todo lo que deba funcionar de forma fiable, es una receta para la frustración. El cambio decisivo: pasar de usuario a director – es decir, dirigir al agente en lugar de mirar cómo improvisa.

Esto vale para Claude Code, porque es la herramienta más extendida en este momento – pero igualmente para cualquier otra herramienta de IA. Y no vale solo para programar: quien ha entendido una vez cómo dirigir a un agente con orden puede calcular presupuestos, elaborar informes o automatizar procesos de negocio completos. No hace falta formación en ingeniería de software.

Del „vibe coding“ al trabajo estructurado

El error más frecuente tiene nombre: „vibe coding“. Se formula una petición, se deja correr al agente y apenas se revisa el resultado. Faltan justo los dos pasos que dan seriedad al trabajo – la planificación previa y la validación posterior.

Una imagen sencilla es la construcción de una casa en un árbol. Primero dibuja un boceto, calcula cuánta madera necesita y dónde, y consigue la herramienta adecuada. Cuando la casa está en pie, no mete allí a los niños sin más – antes comprueba si aguanta. El trato con los agentes de codificación exige la misma disciplina.

Esto importa porque los modelos tienden a la adulación. Si pregunta „¿Esto tiene buena pinta?“, suele llegar un „Sí“ sin que el plan se haya revisado de verdad con espíritu crítico. A la inversa, los modelos afirman de vez en cuando que algo está terminado cuando no lo está. Necesita, por tanto, un método propio e independiente para controlar ambas cosas. El proceso tiene cuatro pasos:

• Planificar – aclarar, con el contexto necesario, qué se va a construir y qué significa el éxito en concreto.
• Construir – delegar la ejecución en el agente en la mayor medida posible.
• Verificar – disponer de una vía propia y clara para comprobar el resultado.
• Mejorar el sistema – el cuarto paso que casi siempre se pasa por alto: extraer de cada ciclo una mejora permanente.

Verificación: pruebas en lugar de afirmaciones

Verificar significa en esencia: „Demuéstrame que está realmente terminado.“ Al programar, eso son las pruebas y el linting – pero el principio se puede trasladar a casi todo. Un ejemplo sin código: el agente crea un diagrama y lo renderiza después como imagen. Como los modelos actuales leen imágenes muy bien, el agente puede mirar su propia obra, detectar solapamientos y corregirlos por su cuenta en varias pasadas. Los errores iniciales dan igual; solo cuenta el resultado final.

El efecto es medible: sin mecanismo de comprobación, el primer resultado quizá alcance de 65 a 70 puntos sobre 100. Con una comprobación integrada, ya en el primer intento son posibles unos 92. Rara vez sale perfecto a la primera – y tampoco se trata de eso. Se trata de darle al agente un marco con el que controle su propio trabajo. La pregunta guía es siempre: ¿Cómo puede el agente comprobar el resultado del mismo modo en que lo haría un usuario real? Una simple mirada al código generado nunca basta.

¿Qué es una „harness“?

Una harness es la envoltura alrededor del modelo de IA – las herramientas y el contexto a los que accede el modelo para saber en qué está trabajando. Imagíneselo como un modelo de capas: en el centro está el modelo, el „cerebro“ propiamente dicho. Alrededor coloca una herramienta como Claude Code. Y encima construye su propia capa – configuración, Skills, hooks y conexiones al CRM o a la gestión de tareas. Es justamente esa capa superior la que convierte una herramienta genérica en su sistema.

Planificación: el paso infravalorado

La mayoría planifica muy poco. Con agentes de codificación dedicará más tiempo a planificar que a construir, porque cede en buena parte la ejecución – el éxito depende así directamente de la calidad del plan. Ha dado buen resultado un único documento que describa el objetivo:

• ¿Qué construimos – y por qué?
• ¿Qué aspecto tiene el éxito en concreto?
• ¿En qué reconoce el agente que el trabajo está terminado y es correcto?
• En tareas técnicas: ¿qué puntos del sistema existente hay que tocar realmente?

El proceso habitual: primero reunir contexto y documentos relevantes, después investigar y, a partir de ahí, desarrollar el plan junto con el agente. Muy importante: deje que el agente haga muchas preguntas, para que no acumule suposiciones sobre el resultado deseado. Solo cuando ha preguntado de forma concreta coinciden persona y agente en qué se debe hacer y cómo se va a comprobar.

Sentirse seguro aun sin saber leer código

¿Cómo se gana confianza en un código que uno no lee? Hay dos caminos. Primero: pida al agente que le explique lo que ha escrito. El código intimida al principio, pero superado el primer obstáculo se lee casi como el inglés. Segundo, si no quiere aprender a programar en absoluto: la confianza nace de la estrategia de validación. Ahí está justamente la diferencia con el vibe coding – usted encaja la ejecución entre un plan cuidadoso y una comprobación igual de cuidadosa, en la que participa usted mismo. El agente recibe luz verde solo cuando está claramente definido cómo demostrará que el trabajo está terminado.

El contexto es escaso: la „dumb zone“

Al planificar, lo más importante es gobernar el contexto, porque la atención de un modelo es un recurso escaso. Circula el malentendido de que da igual cuánto se le cargue al agente, porque los modelos actuales tienen capacidades de contexto enormes. Las cifras son impresionantes – pero hay dos limitaciones.

En primer lugar, el contexto se agota más rápido de lo que se piensa: si el agente lee varias Skills o volúmenes grandes de código, en un instante se han consumido de decenas a cientos de miles de tokens. En segundo lugar, existe la „dumb zone“. En la parte inicial de la ventana de contexto el modelo se muestra afilado y en plena forma. Cuando la conversación supera cierto umbral, la cosa cambia: el modelo parece sobrecargado, pasa cosas por alto y comete errores que con contexto fresco nunca habrían ocurrido.

Por eso debe sopesar con cuidado qué le da al agente de antemano y qué puede descubrir él mismo cuando lo necesite. Esa es precisamente la fuerza de las Skills: ponen a disposición procedimientos y buenas prácticas, pero el modelo decide por sí mismo cuándo necesita qué información. No lo vuelque todo de golpe. Muy a menudo el problema no está en el modelo, sino en la forma en que se llena el contexto. La gran ventana de contexto transmite, pues, una seguridad engañosa – lo mejor es no llegar siquiera al punto crítico.

Orquestar varias sesiones

Como existe la „dumb zone“, no puede meter tareas grandes en una sola sesión. La respuesta es un flujo de trabajo con varias sesiones de agente: un agente planifica y entrega el documento a un segundo para la ejecución, este escribe un informe de ejecución, y un tercero valida y comprueba el trabajo. Es laborioso, pero para software listo para producción o automatizaciones críticas para el negocio es sencillamente necesario.

La imagen para esto es una cadena de montaje: cada agente hace una cosa realmente bien y entrega su resultado de modo que el siguiente tenga contexto suficiente para entender qué se ha hecho, qué queda pendiente y cuál es su tarea actual.

Un ejemplo del día a día B2B: la elaboración de presupuestos, por ejemplo en la construcción o en las artes gráficas. Esos cálculos son laboriosos – estimar el esfuerzo, determinar el material, investigar precios, elegir proveedores. Aquí se construye un flujo de trabajo con agentes especializados: uno comprueba el stock, otro compara precios, otro diseña el PDF. Al final hay una validación – por ejemplo un cálculo que verifica si se alcanza el margen deseado. Quien observa su propia actividad con seriedad reconoce enseguida que se deja descomponer en muchas subtareas pequeñas – y justo esa descomposición genera de inmediato un enorme efecto palanca.

La seguridad va en la técnica, no en el prompt

Una seguridad especialmente engañosa afecta a los permisos. Muchos creen que sus prompts son protección suficiente. No lo son. Si le dice a un agente que jamás borre una base de datos, puede ocurrir igualmente. Si le prohíbe borrar una carpeta, es posible que escriba un script que haga exactamente eso.

Por eso la única postura sostenible es: todo lo que el agente pueda leer o tocar, tarde o temprano lo toca – incluso sin que se lo pidan. Los permisos deben imponerse por vía técnica: con claves de alcance muy limitado o haciendo que ciertas cosas sean sencillamente inalcanzables. Un ejemplo real muestra la trampa: un agente malinterpretó una entrada de su lista de tareas – y a raíz de ello envió un correo con un código de descuento a toda la lista de distribución, pese a que ese correo nunca debía salir.

Un recurso probado son los hooks – pequeños fragmentos de código que se ejecutan ante un evento determinado, por ejemplo justo antes de que el agente use una herramienta. Así puede comprobar si una orden es delicada y bloquearla. Esos mismos hooks sirven para mejorar el sistema por sí solo – por ejemplo, escribiendo automáticamente al final de cada sesión un resumen en un registro diario.

De cada fallo, una mejora permanente

Lo más importante es quizá la evolución del sistema. Si aparece un problema, no lo arregle sin más y siga adelante – tómelo, junto con el agente, como ocasión para preguntar qué se puede mejorar para que no vuelva a ocurrir. Puede que surja una nueva regla en su configuración, un documento de planificación adicional o una Skill ajustada. Así, cada bug se convierte en una mejora permanente.

Una vez establecido este sistema, casi agradecerá los fallos. Y antes de que lleguen a producirse ayuda una pregunta sencilla que casi nadie se atreve a hacer: „¿Qué podría salir mal aquí?“ Haga que el agente construya de forma deliberada casos límite e intente romper la aplicación con entradas problemáticas. Si algo se rompe, vuelve al bucle de comprobación: encontrar el problema, corregirlo y – muy importante – volver a probar. Puede que la corrección no haya resuelto el problema en absoluto.

La actitud adecuada ante la herramienta

Trate la herramienta como a un mentor – la persona más inteligente del mundo que además es su mejor amigo. No se ríe de usted si pregunta algo supuestamente tonto. Pero no todo sirve como pregunta: por la tendencia a la adulación, preguntarle a un modelo por su opinión es delicado. En cambio, resulta excelente para entender cómo funciona algo o dónde hay datos empíricos – en los casos límite, una automatización funciona con una entrada determinada o no funciona. Sin zona gris. Quien necesita una segunda perspectiva enfrenta dos modelos: uno construye y otro hace de abogado del diablo en una sesión separada, en lugar de elogiar sin criterio.

Conclusión: piense como un gestor de producto

El consejo central para terminar: por muy versado o poco versado que sea en lo técnico – considérese el gestor de producto de su agente. No tiene que describir cómo se construye algo. Pero sí tiene que dar forma a la visión: qué construimos y ¿por qué? Déle a la herramienta el porqué – marca el cómo sorprendentemente mucho.

Ese es el núcleo honesto más allá del ruido: los agentes de IA no son una máquina tragaperras ni un remedio milagroso. Son una herramienta potente que llega a ser exactamente tan buena como el marco que usted le dé. Buenos planes, criterios de comprobación claros y la disciplina de aprender de cada fallo – eso le lleva más lejos que cualquier modelo nuevo. Empiece en pequeño: escriba uno de sus procesos, divídalo en subtareas y defina en qué reconoce que el resultado es correcto. El resto lo puede delegar.

Fuente: Este artículo se basa en el vídeo How to Build Effective Claude Code Agents in 2026 de Nate Herk | AI Automation. Los contenidos han sido elaborados de forma independiente y contextualizados para esta edición en español.