//ASScoding: en busca del estándar

Hubo un tiempo en que el desarrollo de software era el Salvaje Oeste. No había convenciones claras, cada equipo improvisaba, y mantener un proyecto era más un acto de fe que de ingeniería. Con los años llegaron los estándares, las buenas prácticas y el oficio.

Hoy, el desarrollo con agentes de IA está exactamente en ese punto. La fiebre del oro ha comenzado de nuevo. Todos corren hacia las nuevas herramientas, cada uno cava en su propio terreno, y nadie sabe muy bien dónde está el verdadero filón.

Herramientas modernas para desarrolladores —cada una con su propia nomenclatura y filosofía— intentan resolver el mismo problema desde ángulos distintos: cómo dar contexto a un agente, cómo enseñarle a trabajar y cómo pedirle resultados concretos sin que todo se convierta en un prompt inmanejable. Es una frontera sin normas, donde cada herramienta establece sus propias reglas.

En medio de este aparente caos empieza a emerger un patrón común. No un estándar formal, pero sí una estructura compartida que aparece una y otra vez en documentación reciente, repositorios reales y flujos de trabajo avanzados. Un descubrimiento que podría cambiar las reglas del juego.

Tres primitivas. Tres artefactos. Un acrónimo imposible de olvidar. ASScoding.

El caos antes del orden

Si observas cómo funcionan hoy los agentes para desarrollo, verás siempre los mismos conceptos, aunque reciban nombres distintos:

• Instrucciones o reglas globales para indicar cómo trabajar
• Capacidades o herramientas concretas para realizar ciertas tareas
• Requerimientos funcionales, de corrección o mejora del producto

Y todo esto se define en lenguaje natural, un poco formalizado en ficheros markdown y alguna que otra cabecera YAML. Este es el nuevo lenguaje de programación. El nuevo oro que todos buscan extraer.

Pero, ahí se acaba el acuerdo. Las herramientas (ClaudeCode, Copilot, Cursor, Antigravity, etc.) evolucionan rápidamente en un entorno altamente competitivo. Y esto hace que cada una resuelva a su manera (intencionalmente o no) el mismo problema de forma distinta. Cada uno cava su propia mina, sin coordinación, sin orden.

Y el problema es que estos ficheros son nuestras nuevas primitivas de programación.

Es como si la sintaxis de Java, Python, o de TypeScript, fueran diferentes en VS Code, IntelliJ o Eclipse.

Necesitamos, y va emergiendo en la industria, un estándar común para estos ficheros, para esta nueva sintaxis. Necesitamos alguien que ponga orden en esta pradera sin normas. Y parece basarse en tres conceptos fundamentales:

• A: AGENTS.md,
• S: skills/*/SKILL.md y
• S: specs/*.spec.md.

Vamos a ver en detalle este trio de ases. ASScoding.

AGENTS.md — La ley del territorio

Inicialmente llamados reglas, fue popularizado por Cursor en sus .cursorrules. Y los demás lo fueron adaptando. Copilot en .github/copilot.instructions.md, ClaudeCode en CLAUDE.md, etc. Cada uno plantaba su bandera en la frontera.

En algún momento alguien propuso el nombre genérico de AGENTS.md para estos ficheros. Y poco a poco se fue imponiendo. Y ahora es el primer gran estándar de la IA para el desarrollo. El primer descubrimiento que todos empezaron a seguir.

Es el equivalente moderno a la Constitución de un sistema. Se escribe poco (debe ser conciso ya que se adjunta a cada prompt y no debe sobrecargar el contexto), se cambia raramente y se respeta siempre. Es el código que la autoridad hace cumplir en su jurisdicción.

¿Y qué debe contener? Pues lo básico:

• Una descripción breve del producto que se va a construir
• El stack tecnológico que se usará para ello
• Los comandos básicos del flujo de trabajo del programador
• Un mapa de carpetas para no perderse
• Especificidades sobre el entorno de desarrollo (S.O., terminal, repositorio…)
• Personalización de la cultura y estilo de conversación

Y todo esto en cuantas menos líneas y más cortas mejor. Ya sabes, el contexto es un tesoro.

skills/*/SKILL.md — El oficio

Un agente sin habilidades explícitas es un improvisador con teclado. Un buscador de oro sin herramientas, cavando a ciegas. Aquí el mérito es Anthropic que evolucionó el sistema de reglas e instrucciones simplonas de Cursor y Copilot en algo mucho más general y potente. Y le llamó Skills. Un descubrimiento que cambió la forma de trabajar.

Como sus predecesoras, las skills describen cómo se hacen las cosas, no qué hay que hacer hoy. Son conocimiento reutilizable pero que va más allá de un conjunto de reglas. Son las técnicas que los mineros veteranos enseñan a los novatos.

Una skill bien escrita:

• Indica su propósito y cuándo debe ser invocada
• Detalla el cómo hacerlo (igual que las reglas e instrucciones)
• Delega en otros ficheros para no saturar el contexto si no es necesario
• Puede incluir, ejemplos, contenido estático, plantillas, y código ejecutable!

Repito sus dos características fundamentales:

• Se descubre automáticamente por contexto y flujo de trabajo
• Más que indicaciones en lenguaje natural, ejemplos, plantillas, y código ejecutable!

Esto no es prompt engineering. Es transmisión de oficio.

specs/*.spec.md — El encargo

Y para el final, lo más importante: a qué hemos venido aquí. A resolver problemas de usuarios. Y la definición de esos problemas, junto con sus soluciones y criterios de aceptación deben ser correcta y completamente especificados para que los agentes los entiendan y los resuelvan. Sin especificaciones claras, estamos disparando a ciegas en un duelo al amanecer.

A ese detalle en lenguaje natural y guardado en ficheros markdown es a lo que llamamos especificaciones, o más sencillamente specs.

Las specs describen el trabajo concreto. Responden a preguntas simples:

• ¿Qué problema se debe resolver detalladamente?
• ¿Qué solución se espera a grandes rasgos?
• ¿Cuándo se considera resuelta?

Al igual que las skills, las specs deben ser completas y detalladas en cuanto a la definición del problema (aunque no tanto en la parte de la solución, que es lo que se va a generar con el agente). Son el mapa del tesoro que indica dónde cavar.

Las specs no explican cómo hacer el trabajo. Para eso están las skills. Las specs ordenan la acción. Son las órdenes del alguacil.

ASScoding: poner orden en el Salvaje Oeste

ASScoding es la práctica de desarrollar software con agentes de IA usando explícitamente:

• AGENTS.md para el contexto general
• skills/ para el conocimiento operativo
• specs/ para el trabajo concreto

No es una herramienta ni un framework. Es una forma de trabajar. Es el código de conducta que falta en esta frontera sin normas.

ASScoding implica que:

• El contexto no se improvisa
• Las habilidades se documentan
• Las especificaciones se detallan

Exactamente igual (o debería ser igual) que el desarrollo profesional antes de la IA. Cuando llegó la autoridad y puso fin al caos del Salvaje Oeste.

Conclusión

El nombre ASS provoca sonrisas. Bien.

Los estándares útiles suelen nacer así: de forma informal, práctica y sin comité. Como los descubrimientos de oro: alguien encuentra un filón, otros lo siguen, y de repente hay una fiebre del oro.

ASScoding no promete magia. Promete orden y facilidad para que los equipos de desarrollo puedan trabajar con distintas herramientas y no se pierdan en el caos. Promete que, después de la fiebre del oro y el caos inicial, llegue la justicia y el orden.

En el Salvaje Oeste del desarrollo con IA, Agents, Skills y Specs, ASS puede acabar siendo el guardián que esta pradera tan desesperadamente necesita. El que pone fin a los duelos sin reglas y establece un código que todos puedan seguir.