Por qué un ingeniero veterano vive creando skills para agentes
La flota de programadores sin memoria
Hay una frase de un ingeniero con casi una década de experiencia que me parece de las más certeras que he oído últimamente: en todo ese tiempo, nunca el proceso ha sido tan importante como ahora. Y tiene toda la razón.
Piénsalo así. Hoy tienes a tu disposición una flota de programadores de nivel medio-bueno que puedes desplegar cuando quieras: los agentes de Inteligencia Artificial. Pero tienen una pega rarísima, casi de ciencia ficción: no tienen memoria. No recuerdan lo que hicieron antes, no aprenden de la sesión de ayer, arrancan a cero cada vez. Y para que una flota así haga algo útil de verdad, necesitas una cosa por encima de todo: procesos clarísimos y bien definidos.
Ahí es donde entran las skills. Y por eso, hoy, crear skills se ha vuelto una de las habilidades más valiosas del desarrollador.
Por qué el proceso manda más que nunca
Cuando programabas tú solo, el proceso vivía en tu cabeza. Sabías cómo se hacían las cosas en tu proyecto, te acordabas de las decisiones, mantenías el hilo. El proceso era implícito, y funcionaba porque tú tenías memoria.
Con los agentes, eso se rompe. Le pides algo a la máquina, lo hace, y al siguiente encargo ya no recuerda ni cómo lo hizo ni por qué. Si no le das un proceso explícito, cada vez improvisa a su manera, y acabas con resultados inconsistentes: hoy lo hace así, mañana asá, y tú detrás recogiendo. La inconsistencia es el gran enemigo de trabajar con agentes.
La única forma de domar eso es escribir el proceso: dejar por escrito, claro y detallado, cómo se hace cada cosa. Es exactamente la idea de los procedimientos que defiendo desde siempre, ahora elevada a necesidad absoluta. Donde antes un proceso claro era una buena práctica, hoy es el requisito para que la flota de agentes sirva de algo.
Las skills: procesos que el agente ejecuta solo
Una skill no es más que eso: un proceso documentado que le das al agente para que lo ejecute siempre igual. Le dices, paso a paso, cómo se hace tal cosa en tu proyecto, y a partir de ahí lo hace a tu manera sin que tengas que repetírselo en cada conversación.
El ingeniero del que hablo tiene un repositorio entero de skills, cada una diseñada por él. Algunas las usa rara vez; otras, cada día. Y ese es el patrón que veo en todo el que trabaja en serio con agentes: vas detectando las tareas que repites, y vas encapsulándolas. ¿Qué tipo de cosas acaban siendo skills de uso diario? Las del oficio:
- Planificar una tarea antes de tocar código, con las preguntas que siempre hay que hacerse.
- Revisar el trabajo contra unos criterios fijos (buenas prácticas, sin romper nada, eficiente).
- Escribir los commits o la documentación con vuestro formato exacto.
- Seguir un procedimiento concreto del proyecto sin saltarse pasos.
No es casualidad que sean justo las tareas donde la consistencia importa. Ahí es donde una skill convierte a un agente errático en uno fiable.
El cambio de mentalidad del desarrollador
Esto redefine un poco qué es ser buen desarrollador hoy. Antes, gran parte del valor estaba en escribir el código tú. Cada vez más, el valor está en dirigir a los agentes que lo escriben: saber qué pedir, cómo trocearlo y, sobre todo, diseñar los procesos que los mantienen en el carril.
Es un trabajo más de director de orquesta que de instrumentista. Y el director que tiene partituras claras (skills bien hechas) saca música; el que improvisa cada vez, ruido. No es que programar deje de importar, es que la palanca de productividad se ha movido a saber encapsular tu forma de trabajar para que la máquina la siga.
Para un equipo o una empresa, esto es enorme: las skills capturan el “cómo lo hacemos aquí” y lo hacen ejecutable por cualquier agente, de forma consistente, sin depender de que cada uno se acuerde. Montar esa base de procesos y skills es justo el tipo de cosa en la que puedo ayudar, porque ahí es donde una empresa gana velocidad sin perder calidad.
Empieza por una, no por veinte
Si todo esto te suena a mucho, tranquilo: no necesitas montar una biblioteca enorme de golpe. Empieza por una sola skill, la de la tarea que más repites y que más pereza te da hacer a mano. Escríbela bien, úsala unos días, y cuando veas el cambio te entrarán ganas de hacer la siguiente. Así, sin agobios, es como se construye con el tiempo ese repositorio de procesos que te convierte en el director de tu flota de agentes en lugar de en su mecanógrafo.
Lo que me llevo de todo esto
La frase del ingeniero se me ha quedado grabada: con una flota de agentes sin memoria, el proceso manda más que nunca. Y la herramienta para mandar ese proceso son las skills. Quien las domina, dirige a sus agentes; quien no, se pasa el día corrigiéndoles improvisaciones.
Mi consejo, igual que con los procedimientos: empieza por las tareas que repites cada día, escribe el proceso claro, conviértelo en skill, y ve construyendo tu propia biblioteca. La máquina pone la velocidad; tú pones el método. Y el método, hoy, vale oro.
Preguntas frecuentes
¿Por qué se dice que el proceso importa más con los agentes?
Porque los agentes de Inteligencia Artificial no tienen memoria entre sesiones: no recuerdan cómo hicieron algo antes, así que sin un proceso explícito improvisan distinto cada vez y dan resultados inconsistentes. Para que una flota de agentes sea útil, necesitas procesos claros y bien definidos que les digan exactamente cómo hacer cada cosa.
¿Qué tareas conviene convertir en skills de uso diario?
Las que repites y donde la consistencia importa: planificar una tarea antes de programar, revisar el trabajo contra criterios fijos, escribir commits o documentación con tu formato, o seguir un procedimiento concreto del proyecto. Son las tareas del oficio que quieres que se hagan siempre igual, y ahí es donde una skill convierte a un agente errático en fiable.
¿Crear skills es la nueva habilidad clave del desarrollador?
Cada vez más. El valor se ha movido de escribir todo el código a dirigir a los agentes que lo escriben: saber qué pedir, cómo trocearlo y diseñar los procesos (skills) que los mantienen en el carril. Es un trabajo más de director de orquesta que de instrumentista, y quien sabe encapsular su forma de trabajar saca mucho más partido a los agentes.
¿En qué se diferencia una skill de un buen procedimiento de toda la vida?
En el fondo son lo mismo: un proceso claro, detallado y siempre igual. La diferencia es que una skill está escrita para que un agente la ejecute directamente, en lugar de para que la siga una persona. Por eso la vieja buena práctica de documentar procedimientos se ha vuelto, en la era de los agentes, una necesidad y una ventaja competitiva.
Fuentes
Compártelo si te ha resultado útil, sobre todo con quien dirija agentes sin haberles escrito ni un proceso.
¿Qué tarea repetida vas a convertir en tu primera skill? Cuéntame.
Y… la máquina pone la velocidad; el método, lo pones tú.
Artículos relacionados
Crisis de confianza en Anthropic: qué pasó y cómo afecta a devs
Anthropic ha vivido un abril de 2026 para el olvido, con limitación de agentes gratuitos, cambios sin avisar en Claude Code, un nuevo tokenizador que encarece precios un 45% y errores de facturación como el caso Hermes. Repasamos una crisis de confianza que ha sacudido a la comunidad de desarrolladores este mes.
Routines de Claude Code: automatiza sin el ordenador encendido
Anthropic acaba de soltar una función en Claude Code que cambia las reglas de la automatización: las Routines. Hasta ahora, para que un agente hiciera tareas solo y en bucle (revisar correos, montar un resumen diario, vigilar algo) necesitabas una herramienta como n8n y, muchas veces, un ordenador o un servidor encendido. Con las Routines puedes lanzar automatizaciones agénticas programadas o por eventos que corren en la infraestructura de Anthropic, sin tu equipo encendido, con la misma suscripción de Claude que ya pagas. Aquí te cuento qué son, qué puedes hacer con ellas, en qué se diferencian de n8n y por qué esto acerca a Claude Code a competir de tú a tú con las plataformas de automatización de toda la vida.
Harness engineering: por qué el entorno importa más que el modelo
Habrás notado algo raro usando ChatGPT, Claude o Copilot: a veces hacen cosas increíbles y a veces fallan en lo más tonto. Y resulta que gran parte de los saltos de calidad de los últimos tiempos no han venido de modelos más listos, sino de mejores entornos donde esos modelos se ejecutan. A esos entornos se les llama arneses (harness), y a la disciplina de construirlos bien, harness engineering. Aquí te explico qué es un arnés, por qué importa tanto, y cómo dejar de tratar la Inteligencia Artificial como un simple chatbot para empezar a construir sistemas de verdad encima de los modelos. Porque ahora que generar código es fácil y rápido, el problema ya no es escribirlo, es controlar el caballo desbocado que lo genera.