Comparación entre DevSpeak y un chatbot general bien prompteado para generar especificaciones técnicas. Ambos producen buen resultado en una sola ejecución. La diferencia es que la audiencia es un parámetro tipado en DevSpeak y no una frase dentro de un prompt, así que el mismo texto de entrada produce de forma fiable un documento distinto para una persona junior que para un SRE. Incluye una ejecución real comparada y el prompt exacto y reproducible del chatbot.
DevSpeak frente a un prompt normal de ChatGPT: un requisito, cinco audiencias
Nuestro competidor real no es otra herramienta de especificaciones. Es una persona desarrolladora con una pestaña de ChatGPT abierta y un prompt que lleva seis meses afinando. Cualquier comparación honesta tiene que empezar ahí, y tiene que empezar admitiendo lo evidente: ese prompt funciona.
DevSpeak ofrece cinco audiencias: Dev Junior, Dev Senior, Líder Técnico, SRE e Ingeniero de Datos. Este artículo pasa un mismo requisito por dos de ellas, Dev Junior y SRE, y compara los resultados lado a lado.
Admitamos la parte que sí funciona
Dale a un modelo general moderno un requisito claro y un prompt bien escrito y obtendrás una especificación técnica utilizable. No mediocre: realmente buena, con encabezados sensatos, casos límite razonables y un modelo de datos que no te daría vergüenza revisar.
Si tu flujo de trabajo es "escribo una especificación, la leo yo, empiezo a programar", no necesitas una herramienta especializada para eso. Necesitas un buen prompt, y ya lo tienes. Cualquier proveedor que te diga lo contrario te está vendiendo algo que puedes conseguir gratis.
Así que este artículo no trata de si un chatbot puede escribir una especificación. Puede. Trata de qué pasa la segunda, la tercera y la cuarta vez que necesitas ese mismo requisito.
La prueba: una entrada, dos audiencias
Este es el requisito, escrito como lo escribe de verdad una persona de negocio: vago, conversacional y con restricciones que no llega a enunciar.
`` When someone's card gets declined we shouldn't just kill their account right away. Give them a bit of time to fix it and let them know. Also make sure they can still read their stuff while it's being sorted out.text
`
Está deliberadamente sin pulir. Los requisitos reales llegan así.
En DevSpeak esto es una petición con parámetros tipados. El texto de entrada es un campo; la audiencia es otro:
`json
{
"input": "When someone's card gets declined we shouldn't just kill their account right away. Give them a bit of time to fix it and let them know. Also make sure they can still read their stuff while it's being sorted out.",
"audience": "Junior Dev",
"context": "Backend",
"format": "Technical Spec",
"tone": 50
}
`
Lo ejecuté contra producción y después cambié exactamente una secuencia de caracteres — "Junior Dev" por "SRE" — y lo ejecuté otra vez. La cadena input fue idéntica byte a byte en ambas ejecuciones. Nada más cambió.Lo que devolvió
Ambos documentos compartieron un esqueleto: resumen, arquitectura, contrato de API, modelo de datos, seguridad y preguntas abiertas. Por debajo de ese nivel divergieron de formas que corresponden a aquello de lo que cada lector es responsable.
El documento para SRE produjo una sección de operación que el documento junior no tenía en absoluto. Especificó sobre qué alertar:
`text
- Grace period expiration rate exceeds threshold
(e.g., >10% of declined accounts).
- Notification delivery failure rate exceeds 5%.
- Accounts stuck in PAYMENT_DECLINED state beyond grace period
(indicates scheduler failure).
`
El tercer punto es el interesante. Nada en la entrada mencionaba un planificador. El documento dedujo que una transición de estado basada en tiempo implica un proceso en segundo plano, y que una cuenta atascada es el síntoma observable de que ese proceso falla. Ese es el razonamiento que aplicaría un SRE al leer el requisito, puesto en el documento en lugar de dejárselo a esa persona.
El documento para junior gastó su extensión en otra parte. Donde la versión SRE tenía monitorización, esta tenía un patrón de implementación detallado paso a paso:
`text
- Query account state before processing write requests.
- If grace_period_active, return HTTP 403 Forbidden with error code
ACCOUNT_IN_GRACE_PERIOD.
- Include remediation instructions in error response body.
`
También añadió una sección de condiciones de carrera que la versión SRE omitió, sobre qué ocurre cuando un pago se completa mientras el proceso de expiración está en marcha. No porque a un SRE no le importe, sino porque para ese lector se da por supuesto, y para alguien junior es justo el error que está a punto de escribir.
El documento junior resultó cerca de un 30% más largo que el de SRE. Más explicación, menos supuestos. Esa es la dirección correcta para la audiencia, y ninguna de las dos extensiones fue algo que yo pidiera.
Donde ambas herramientas llegan al mismo sitio
Los dos documentos señalaron que la duración del periodo de gracia nunca se especificó, y ninguno se inventó un valor en silencio. La versión SRE recomendó de 7 a 14 días etiquetándolo como un supuesto que requiere ajuste según el despliegue.
Un chatbot bien prompteado también hace esto. Señalar restricciones no enunciadas es una propiedad de un modelo capaz, no de un producto especializado, y DevSpeak no merece ningún mérito por ello.
Ejecuta tú la comparación
La forma honesta de evaluar esto es reproducirlo, no fiarte de una captura de pantalla. Pega esto en ChatGPT con el mismo requisito:
`text
You are a senior engineer writing a technical specification for a
backend feature. Write the spec for a Junior Dev audience, at a
moderate level of detail.
Include: abstract, architecture, API contract, data model, security
considerations, and open questions. Flag any constraint the
requirement leaves unspecified rather than inventing a value.
Requirement:
When someone's card gets declined we shouldn't just kill their account
right away. Give them a bit of time to fix it and let them know. Also
make sure they can still read their stuff while it's being sorted out.
`
Después ejecútalo otra vez cambiando Junior Dev por SRE y compara ambas salidas entre sí.
Publico el prompt y no una transcripción a propósito. El comportamiento de los modelos cambia —en el momento de escribir esto, el modelo insignia de OpenAI es GPT-6 Astra, con fecha de corte de conocimiento del 30 de abril de 2026— y una captura de una sesión con un modelo no es evidencia que puedas comprobar. Un prompt que puedes ejecutar hoy sí lo es.
Lo que sí voy a predecir, y que deberías verificar en lugar de creerme: la ejecución única será buena. La pregunta es si la segunda difiere de la primera en lo que importa, y si lo hace igual la semana que viene.
La diferencia es el contrato, no la calidad
En ese prompt, la audiencia es una frase. Las frases son sugerencias: compiten con todo lo demás en la ventana de contexto y su influencia varía según la redacción, la posición y lo que hayas pegado encima.
En DevSpeak, audience es un campo tipado con cinco valores permitidos: Junior Dev, Senior Dev, Tech Lead, SRE y Data Engineer. También lo son context, format y tone`. Si envías una sexta audiencia, la petición se rechaza en la validación; no recibe una interpretación aproximada.
Esto importa de una forma concreta, y conviene ser preciso sobre qué te da y qué no:
Esa es toda la afirmación. No un resultado mejor, sino un contrato estable alrededor del mismo resultado, que es lo que necesitas en cuanto hay más de una persona o más de un documento de por medio.
Cuándo no deberías molestarte
Usa el chatbot si escribes especificaciones de vez en cuando, para un solo lector, y ese lector eres tú. El coste de adoptar una herramienta no compensa, y fingir lo contrario sería deshonesto.
La economía cambia cuando la traducción se vuelve repetitiva: el mismo requisito para cuatro audiencias, el mismo formato cada sprint, o un paso de especificación dentro de una pipeline donde "quien tiene el prompt bueno" no es una dependencia aceptable. Generar la especificación es gratis en todos los planes de DevSpeak. Iterar sobre un documento generado y acceder al motor mediante programación es lo que añaden los planes de pago.
El criterio sobre qué debe hacer una funcionalidad sigue siendo tuyo en ambos casos. Solo el reescribir es mecánico, y el trabajo mecánico es el que merece tener un contrato alrededor.