Markdown vs. Sudolang para prompts: qué elegir en 2026

Sudolang es un pseudo-lenguaje de programación diseñado específicamente para comunicarse con LLMs de forma más estructurada que el lenguaje natural o el Markdown convencional. Su premisa era atractiva: usar una sintaxis similar a la de un lenguaje de programación para describir comportamiento, condiciones y reglas — reduciendo la ambigüedad del lenguaje natural y, en teoría, los tokens necesarios para transmitir la misma información.

NAST (Natural Abstraction Syntax Tree) siguió una filosofía similar: representar el prompt como un árbol de instrucciones estructurado, más cercano a la forma en que los modelos procesan internamente la información. Ambas propuestas generaron interés en 2023-2024 entre equipos que buscaban optimizar el consumo de tokens.

// Ejemplo conceptual de Sudolang
function validarEmail(email) {
  if (email matches /^[\w.]+@[\w.]+\.[a-z]{2,}$/) {
    return { valid: true }
  } else {
    return { valid: false, reason: "Formato inválido" }
  }
}

// Equivalente en Markdown (más verboso, igual de claro para el LLM)
// Función: validarEmail
// Input: string con dirección de email
// Output: { valid: boolean, reason?: string }
// Regla: validar contra expresión regular estándar de emails
// Error: devolver valid=false con reason explicativa

Qué dice la evidencia

Los resultados empíricos son más matizados de lo que los defensores de Sudolang prometían. Varios equipos que realizaron benchmarks comparativos encontraron que la reducción de tokens era real en algunos tipos de tareas — principalmente las que describen lógica algorítmica — pero que en otros casos Sudolang producía prompts más largos que Markdown debido a la necesidad de definir explícitamente la semántica del pseudo-lenguaje.

La precisión del output también mostró resultados mixtos: mejoró en tareas donde la estructura importaba mucho (generación de funciones, validaciones), pero no mostró ventaja estadísticamente significativa en tareas de razonamiento o de generación de documentación. Además, los resultados dependen fuertemente del modelo: modelos más recientes gestionan igualmente bien instrucciones en Markdown estructurado.

Por qué Markdown sigue ganando en equipos

En la práctica, la mayoría de equipos que exploran alternativas a Markdown terminan volviendo a él. Las razones son consistentes:

Hay que tener en cuenta que el coste de adoptar un formato alternativo no es solo técnico. Cada nuevo miembro del equipo necesita aprender el pseudo-lenguaje; cada revisión de prompt es más lenta; los errores de sintaxis del DSL producen comportamientos inesperados que son difíciles de diagnosticar.

Hay contextos donde la experimentación con formatos alternativos tiene sentido y bajo coste:

Lo que no tiene sentido es adoptar Sudolang en un equipo distribuido donde no todos los miembros tienen el mismo nivel técnico, o donde los prompts son redactados por personas de producto sin perfil de desarrollo.

La regla pragmática

Elegir el formato en el que el equipo ya escribe. Si todo el mundo usa Markdown para documentar, usar Markdown para los prompts. La fricción de cambiar de formato tiene un coste real que rara vez compensa la ganancia marginal de tokens.

El mayor ROI en prompting está en la calidad y completitud del contenido, no en el formato. Un prompt en Markdown bien estructurado, con contexto suficiente, ejemplos concretos y criterios de aceptación claros, produce outputs mejores que un prompt en Sudolang mal escrito o incompleto.