Martin Fowler publicó un artículo extenso que propone una tesis contracorriente: los agentes de IA funcionan mejor cuando operan dentro de un Domain-Specific Language (DSL) que cuando les pides cualquier cosa en lenguaje natural. El dominio restringido no es una limitación, es una guía: el agente comete menos errores porque el vocabulario posible es más pequeño y más preciso.

El artículo parte de la imposibilidad de la especificación completa previa y llega a una observación práctica: quienes usan Claude Code o Codex en codebases bien estructuradas obtienen resultados más confiables que quienes les piden construir desde cero sin restricciones. El texto documenta dos ejemplos concretos: un sistema para generar presentaciones PowerPoint ricas en diagramas y Tickloom, un DSL para ilustrar comportamientos de sistemas distribuidos. En ambos casos, el modelo aprende el lenguaje del dominio y lo usa como interfaz natural, produciendo resultados más verificables.

Por qué te importa: si estás diseñando un agente para una tarea repetida en tu campo, restringir el lenguaje en lugar de dejarlo libre puede ser la diferencia entre una herramienta confiable y un generador de sorpresas. La idea también atraviesa la lección sobre el primer agente útil: el objetivo y los límites declarados no son burocracia, son el DSL implícito de tu agente.

En detalle

El contexto que faltaba.

Los agentes de IA nacieron con la idea de trabajar en lenguaje natural abierto: pides lo que quieres y el modelo decide los pasos. Fowler invierte la perspectiva: el lenguaje natural es demasiado amplio para un dominio específico. Cuando diseñas un agente para una tarea repetida—generar diagramas arquitectónicos, probar escenarios distribuidos, producir reportes estructurados—tienes un vocabulario limitado de operaciones y entidades. Explicitar ese vocabulario en un DSL (incluso muy simple) le da al agente una interfaz más precisa y verificable.

El artículo desarrolla el argumento a través de dos casos:

1. Presentaciones PowerPoint ricas en diagramas. Un modelo semántico de las diapositivas (título, viñetas, diagrama, notas) se convierte en el DSL. El usuario describe en lenguaje natural lo que quiere comunicar, el LLM genera el DSL, un segundo paso lo transforma en PowerPoint. El punto: separar la generación semántica (controlable) de la representación final (mecánica).

2. Tickloom: un DSL para sistemas distribuidos. Fowler y su equipo construyeron un lenguaje mínimo para describir interacciones entre nodos en un sistema distribuido (mensajes, fallos, reintentos). El LLM lee descripciones textuales de escenarios y genera Tickloom, que luego produce el diagrama. El DSL actúa como contrato: si la salida no compila, el error es inmediatamente reconocible.

La tesis central es que el DSL se convierte en la fuente de verdad: la salida verificable no es el texto generado por el LLM, sino el código DSL que el LLM ha producido. Un DSL bien hecho es más fácil de parsear, probar y corregir que una respuesta en prosa.

Convergencia con Claude Code y Codex.

La idea resuena con la experiencia de quienes usan agentes de codificación en producción. Claude Code y Codex funcionan mejor en codebases con abstracciones claras y convenciones consistentes—de hecho, un DSL implícito. Cuando la estructura es débil, el agente genera código que compila pero no se integra, o hace suposiciones erróneas sobre los límites.

Fowler cita Domain-Driven Design y el Lenguaje Ubicuo: construir un modelo conceptual compartido siempre ha sido la forma de hacer crecer software complejo. El LLM acelera el proceso, pero no lo sustituye: el LLM ayuda a descubrir el vocabulario correcto, luego lo usa.

Los límites y qué sigue abierto.

El artículo no aborda dos problemas prácticos:

• ¿Quién escribe el DSL? Fowler describe el proceso iterativo (el LLM como socio de lluvia de ideas), pero no dice cuánto tiempo se necesita para llegar a un DSL estable. Si el dominio cambia a menudo, el DSL se convierte en una segunda base de código que mantener.
• Cuándo el DSL no es suficiente. Hay tareas donde el vocabulario es realmente abierto (escritura creativa, exploración de ideas). Fowler no discute cuándo el lenguaje natural es la opción correcta.

La discusión en Hacker News (121 puntos, 80 comentarios) confirma que la idea encuentra apoyo en quienes desarrollan agentes: muchos reportan que restringir el dominio reduce errores y simplifica el debugging. Otros plantean la duda opuesta: construir un DSL tiene sentido solo si la tarea es realmente repetida, de lo contrario el costo de diseño supera el beneficio.

Implicaciones para quienes diseñan agentes.

Si estás construyendo un agente que resuelve el mismo tipo de problema muchas veces, considera definir explícitamente el vocabulario de operaciones y entidades en lugar de dejar que emerja del prompt. No necesitas un lenguaje formal: incluso un esquema JSON o una lista de comandos reconocidos es un DSL.

El método se vincula a dos herramientas del sitio:

• La lección sobre el primer agente útil insiste en objetivo y límites declarados: ese contrato implícito ya es un DSL mínimo.
• El playbook para escribir especificaciones ejecutables propone definir criterios de aceptación antes de generar: allí también, estás restringiendo el dominio para obtener resultados verificables.

Fowler cierra con una observación que vale para todo el trabajo con agentes: el DSL es el lugar donde el diseño y la generación se encuentran. El LLM acelera, pero el diseño—decidir qué importa y qué no—sigue siendo tu responsabilidad.