luismori.

AI Coding Workflows

LLM AI Agents Agent Skills

Anticipa el camino: la sencilla razón por la que funcionan las reglas, las skills y los agentes

Los LLM terminan las tareas cuando primero les muestras el camino. La persona casi siempre tiene más contexto que el modelo, así que una solicitud abierta es un laberinto de suposiciones. En cambio, anticipar un camino con pasos, restricciones y verificaciones convierte el deambular en avanzar. Aquí te explico por qué las reglas, las skills y el scaffolding son el mismo truco.

16 min de lectura Actualizado el 11 sept 2026
Anticipa el camino: la sencilla razón por la que funcionan las reglas, las skills y los agentes

Imagina dos formas de pedirle ayuda a un colega.

La primera: «Oye, el pipeline de deploy está fallando. Arréglalo». Y te vas.

La segunda: «El pipeline de deploy está fallando. Empieza por los logs de staging de la ejecución de anoche; probablemente ahí esté el error. Si es el paso de migración, reviértelo y vuelve a ejecutar con el snapshot anterior. Si es cualquier otra cosa, detente y envíame el error. No toques producción».

El mismo colega. El mismo pipeline que falla. Probabilidades radicalmente distintas de obtener un buen resultado.

Ahora cambia al colega por un modelo de lenguaje y tienes toda la historia de este artículo. La inferencia de un LLM funciona mejor —y realmente termina la tarea— cuando anticipas primero el camino correcto. Las solicitudes abiertas hacen que el modelo deambule por un laberinto de posibilidades. Un camino anticipado convierte el laberinto en un sendero señalizado: estos son los pasos, estas son las restricciones y así sabes que terminaste.

Vuelvo una y otra vez a esta idea porque explica muchísimo. Una vez que la ves, los archivos de reglas, las Agent Skills, los system prompts, los workflows guiados por especificaciones y los guardrails dejan de parecer técnicas distintas. Todos son el mismo truco con distintos nombres: una persona que conoce el contexto traza el camino para que el modelo no tenga que descubrirlo a base de suposiciones.

Tú sabes más que el modelo. Siempre.

Este es el incómodo punto de partida: para la mayoría de las tareas, tienes mucho más contexto del que la IA llegará a tener. Sabes qué sistema falla de forma intermitente, qué stakeholder es exigente, qué significó «terminado» la última vez, qué atajo es seguro y cuál causó un incidente en marzo. El modelo ve unos cuantos párrafos de texto.

Los investigadores tienen un nombre para el entendimiento compartido que construyen dos colaboradores: common ground. Las personas lo mantenemos constantemente sin pensarlo: preguntamos «¿qué quieres decir con eso?», decimos «entendido» y verificamos antes de actuar ante una instrucción vaga. Resulta que los modelos de lenguaje no son buenos en esto. Un estudio de NAACL de 2024 sobre la construcción de entendimiento en una conversación encontró que, en comparación con las personas, los LLM generan lenguaje con menos esfuerzo por construir ese entendimiento y, en cambio, simplemente dan por hecho que existe un entendimiento compartido: actúan como si ya lo hubiera. Más revelador aún: el entrenamiento con datos de preferencias actuales, del tipo que recompensa respuestas rápidas y útiles, en realidad redujo el comportamiento del modelo orientado a construir ese entendimiento. Los entrenamos para responder rápido, no para preguntar primero.

Así que, cuando le asignas a un modelo una tarea insuficientemente especificada, no hace una pausa para entrevistarte. Elige una interpretación y sigue adelante. El estudio de Edwards y Schuster de 2026 sobre agentes de código le da un nombre a esto: incertidumbre externa, es decir, la incertidumbre causada por entradas ambiguas, en contraste con la incertidumbre interna inherente al propio modelo (una distinción que toman de Li et al.). Su solución requiere mecanismos deliberados: un scaffold multiagente que desacopla la detección de especificaciones insuficientes de la ejecución de código y alcanza una tasa de resolución del 69.4% en una variante de SWE-bench con especificaciones insuficientes. Sin esos mecanismos, el comportamiento predeterminado es: asumir, generar y esperar lo mejor.

Y aquí está lo que duele: distintos modelos harán suposiciones diferentes. Cada uno trae consigo supuestos previos distintos de su entrenamiento: cómo es un proyecto «normal», cuál es el siguiente paso «obvio», cuánto explicar en lugar de simplemente actuar. Dale el mismo prompt vago a tres modelos distintos y puedes obtener tres planes contradictorios, todos presentados con seguridad. Esta es mi interpretación como ingeniero al observar cómo divergen los modelos ante tareas insuficientemente especificadas, no una constante medida.

Lo que sí se ha medido: un estudio de 2026 sobre el entendimiento tácito entre personas e IA hizo que 241 personas y 200 agentes condicionados por perfiles ubicaran conceptos a lo largo de espectros subjetivos. Encontró que la alineación estaba asociada con rasgos individuales —características personales, estilos de toma de decisiones, confianza—, mientras que el condicionamiento por perfiles solo capturaba parcialmente una alineación más profunda. En otras palabras, cuando los objetivos son vagos, el éxito depende de un contexto implícito que el modelo no puede ver. Cuanto más vaga sea tu solicitud, más espacio tendrán los supuestos previos de cada modelo para alejarse de lo que realmente querías.

Este es el laberinto. Cada palabra ambigua en tu prompt es una bifurcación, y el modelo debe elegir una dirección en cada una, a ciegas.

Qué significa realmente «anticipar el camino»

Anticipar el camino no significa escribir la respuesta tú mismo. Significa encargarte de la navegación, que es lo que peor hace el modelo, y dejarle la ejecución, que es lo que mejor hace. En la práctica, se ve así:

  • Indica los pasos en orden. No digas «migra la base de datos». Di: primero crea un snapshot, luego ejecuta la migración en staging, después verifica los conteos de filas y finalmente haz el cambio.
  • Define las restricciones de los resultados. Indica qué forma debe tener el resultado: un archivo aquí, una tabla con estas columnas, un plan que siga esta plantilla.
  • Declara qué está fuera de los límites. Lee estos directorios, nunca escribas en aquellos. Trabaja en staging, nunca en producción.
  • Define qué significa «terminado». Una verificación, una prueba, una condición comprobable; no una impresión.
  • Indica qué hacer si se pierde. Detenerse y preguntar. Revertir. Nunca improvisar en silencio para pasar por alto un error.

Nada de esto es extraordinario. Si has escrito un buen runbook, una lista de verificación o un comentario cuidadoso en una revisión de código, ya has anticipado un camino. La clave es que, para los LLM, esto no es algo opcional: es la diferencia entre terminar y dar palos de ciego. Cada paso explícito elimina una bifurcación del laberinto. Cada restricción poda ramas que el modelo exploraría de otro modo. Cada verificación detecta un giro equivocado a tiempo, cuando corregirlo todavía cuesta poco.

La literatura de investigación sigue redescubriendo esto desde distintos ángulos. Least-to-most prompting mostró que dividir un problema difícil en subproblemas más sencillos y resolverlos en secuencia permite a los modelos resolver tareas en las que falla un chain-of-thought directo. El trabajo de Anthropic sobre descomposición de preguntas encontró que descomponer no solo mejora la precisión: también hace que el razonamiento del modelo sea más fiel, más conectado realmente con su respuesta. El patrón ReAct alterna el pensamiento con la acción y la observación, de modo que cada paso se fundamenta en lo que acaba de suceder en lugar de quedar flotando en la especulación. Y una investigación muy reciente sobre planificación hace explícito el mecanismo: el framework Constraints-of-Thought convierte cada paso de razonamiento en una restricción ejecutable que restringe el espacio de acciones posibles, y reporta menores factores de ramificación y mayor precisión en tareas de planificación, código y razonamiento. Reduce el espacio y obtén mejores resultados. La misma historia, con matemáticas más elaboradas.

Incluso las guías oficiales sobre prompts lo dicen claramente. La documentación de mejores prácticas de Anthropic recomienda ser específico sobre los resultados deseados, proporcionar pasos secuenciales cuando el orden importa y restringir explícitamente el razonamiento y el formato. No es un consejo de estilo. Es anticipación del camino, en su forma más sencilla.

Las reglas, las skills y el scaffolding son el mismo truco

Ahora viene la parte divertida: una vez que entiendes la idea del camino, todo el ecosistema de herramientas para agentes cobra sentido.

Un archivo de reglas (AGENTS.md, las reglas de Cursor o lo que lea tu harness) es un camino anticipado para cada tarea de tu repositorio: cómo estructuramos el código, qué comandos son seguros y qué significa «terminado» aquí. Un system prompt es un camino anticipado para toda una sesión: quién eres, qué herramientas tienes y cómo debes comportarte ante la incertidumbre. Una Agent Skill es un camino anticipado para una familia de tareas específica: el conocimiento del dominio, los scripts, los ejemplos desarrollados y los pasos de validación, empaquetados para que el agente no tenga que reinventarlos cada vez.

Esta es exactamente la razón por la que funcionan las skills, y ahora tenemos cifras que lo respaldan. SkillsBench, un benchmark de 2026 que ejecutó 87 tareas en 8 dominios bajo condiciones comparables sin Skills y con Skills seleccionadas para 18 configuraciones de modelo y harness, encontró que las skills seleccionadas elevaron la tasa promedio de éxito del 33.9% al 50.5% (+16.6 puntos porcentuales), con mejoras por configuración de entre +4.1 y +25.7 puntos. En cambio, las skills generadas por los propios agentes quedaron por debajo de la línea base sin skills en las tres configuraciones con harness dedicado (-8.1 a -11.5 puntos). Las skills enfocadas con un máximo de tres módulos superaron a los paquetes más grandes, y volcar documentación exhaustiva apenas produjo un cambio (+0.7 puntos).

Lee eso de nuevo, porque ahí está toda la tesis en un solo resultado: una persona que conoce el camino lo escribe, el agente lo recorre y tiene éxito. Pídele al agente que anticipe su propio camino desde cero y no ganas nada: pierdes terreno. El valor nunca fue «más contexto». Fue el camino correcto, anticipado por alguien que lo conocía.

Los workflows guiados por especificaciones son la misma idea a mayor escala. Antes escribí sobre cómo las seis skills de Spec Kit funcionan como pasadas de un compilador: cada etapa transforma un artefacto en el siguiente con entradas, salidas y verificaciones explícitas. Vuelve a mirar esa arquitectura desde la perspectiva del camino y resulta obvio lo que sucede: especificar, aclarar, planificar, dividir en tareas, analizar e implementar. Cada pasada anticipa el camino para la siguiente, de modo que ninguna llamada al modelo enfrenta todo el laberinto de una sola vez. El paso de «aclarar» merece una mención especial: es un mecanismo explícito para el problema del entendimiento compartido, que convierte la ambigüedad de alto impacto en decisiones registradas antes de que comience el trabajo costoso, en lugar de dejar que el modelo dé por hecho ese entendimiento en silencio.

Los guardrails y los verificadores también son anticipación del camino, solo que desde el otro extremo. Una suite de pruebas, un verificador de tipos, una validación de políticas: todas son formas de decir «el camino correcto debe pasar por aquí». Mi criterio como ingeniero, respaldado por el patrón que se repite en todas las fuentes de este artículo: las verificaciones deterministas son la forma de anticipación de mayor impacto, porque no solo sugieren el camino, sino que obligan a seguirlo.

Un antes y un después que puedes copiar

Basta de teoría. Aquí está el patrón aplicado a algo concreto: pedirle a un agente que agregue limitación de tasa a un endpoint de API.

La versión abierta:

Add rate limiting to the /export endpoint.

Ahora el modelo tiene que adivinar: ¿qué biblioteca de limitación de tasa? ¿Por usuario o por IP? ¿Qué límites? ¿Dónde va la configuración? ¿Cómo debe ser la respuesta de error? ¿Hay que actualizar las pruebas? Cada suposición es una bifurcación, y los errores se acumulan: una elección de biblioteca que parece razonable pero es incorrecta contamina todos los pasos posteriores.

La versión con el camino anticipado:

Add rate limiting to the /export endpoint.

Path:
1. Check package.json — if a rate-limit library is already a dependency, use it.
   Otherwise stop and tell me which one you'd add.
2. Limit per authenticated user, 100 requests/minute, configured in
   src/config/rateLimits.ts next to the existing entries.
3. Return HTTP 429 with the shared error envelope from src/lib/errors.ts.
4. Add one test mirroring tests/rateLimit.auth.test.ts for the new endpoint.
5. Run npm run test:rateLimit. All tests must pass.

Do not: change any other endpoint, add new dependencies without asking,
or modify the error envelope.

El mismo modelo, la misma tarea. La segunda versión elimina casi todas las bifurcaciones: la elección de la biblioteca, la ubicación de la configuración, la estructura del error, el patrón de pruebas, la definición de terminado y los guardrails. Lo que le queda al modelo es trabajo real de ejecución —leer código, escribir el parche, ejecutar pruebas—, que es precisamente lo que hace bien.

Fíjate en lo que no hice: no escribí el código. No especifiqué cada detalle («usa exactamente estas 14 líneas»). La anticipación trata del camino, no de cada pisada. Restringir demasiado tiene su propia forma de fallar: un modelo obligado a seguir un camino equivocado, sin espacio para advertirlo, fallará con seguridad. Por eso el paso 1 dice «detente y avísame» en lugar de fingir que lo sé todo. La persona anticipa; el modelo todavía puede levantar la mano.

Dónde falla esta idea (con honestidad)

Un buen modelo mental también debería decirte dónde deja de funcionar. Vale la pena mencionar tres límites:

Un camino anticipado equivocado es peor que ninguno. Si tus pasos incorporan una suposición incorrecta —la tabla equivocada, una API desactualizada, la arquitectura del trimestre pasado—, el modelo avanzará con seguridad en la dirección equivocada. La variación de SkillsBench entre dominios da pistas de esto: las skills ayudaron mucho en promedio, pero 13 de 87 tareas mostraron diferencias negativas, y la auditoría atribuyó los fallos a pipelines demasiado pesados, estrategias nativas desplazadas y métodos de resolución prescritos pero frágiles. La anticipación amplifica el criterio que se puso en ella, sea bueno o malo. Por eso las mejores skills se construyen a partir de fallos observados en los agentes y se mejoran de manera iterativa, no se escriben una sola vez desde la teoría. La propia guía de Anthropic recomienda empezar por las evaluaciones: observa dónde tiene dificultades el agente y luego escribe la skill que resuelve eso.

Algunas tareas realmente necesitan exploración. Depurar un fallo nuevo, investigar un repositorio desconocido, hacer una prueba inicial de un prototipo abierto: aquí el camino todavía no existe y declararlo prematuramente solo deja al agente a ciegas. Lo correcto es un metacamino: anticipar cómo explorar (ponerle un límite de tiempo, reportar los hallazgos en este formato, proponer tres opciones antes de comprometerse con una) en lugar de anticipar la respuesta.

Las personas son el cuello de botella, y ese es el punto. El hallazgo de SkillsBench de que las skills autogeneradas quedan por debajo de la línea base invita a la humildad. El modelo no puede anticipar su propio camino de manera confiable porque le falta precisamente el contexto del que estamos hablando: tus sistemas, tus estándares, tus cicatrices. Anticipar el camino es el trabajo de la persona en el proceso. También es, diría yo, la habilidad duradera de la era de la IA: los ingenieros que prosperen no serán quienes escriban más código, sino quienes tracen los caminos más claros.

El inicio del sendero

Déjame llevarte de vuelta al comienzo: dos formas de pedir ayuda.

«Arregla el pipeline de deploy» es un laberinto: docenas de bifurcaciones, cada una una suposición, con tres modelos distintos listos para hacer tres suposiciones diferentes. La versión por etapas —primero los logs, revertir la migración si ocurre X, detenerse e informar si ocurre Y, nunca tocar producción— es un sendero señalizado. El mismo modelo lo recorre. Una caminata completamente distinta.

Así que la próxima vez que un agente se desvíe, no termine el trabajo o entregue algo incorrecto con total seguridad, intenta hacerte una pregunta antes de culpar al modelo:

¿Anticipé el camino o solo señalé hacia el bosque?

Lista de fuentes

Priorizo los artículos originales, la documentación oficial y los benchmarks por encima de los comentarios de terceros. Las interpretaciones sobre el significado de todo esto son mi propio criterio como ingeniero.