DevSpeak es una plataforma de IA que convierte requisitos informales en especificaciones técnicas para cualquier lenguaje o framework, en app web, extensión de VS Code, CLI y servidor MCP. Opera en tres etapas: Optimizar, Traducir y Refinar. Los Context Projects anclan el resultado bajo una regla de mundo cerrado; lo no especificado va a Supuestos y Preguntas Abiertas. El XML se valida antes de entregarse, la conmutación automática sortea caídas de proveedores y cada versión queda como snapshot inmutable.
Cómo funciona DevSpeak: una arquitectura que muestra sus vacíos en lugar de adivinar
El fallo costoso en una especificación generada por IA no es una respuesta equivocada. Es una respuesta segura de sí misma escrita encima de un hueco en la entrada: una ruta de archivo que nunca existió en el repositorio, una decisión de diseño que nadie tomó, una respuesta vacía reportada como éxito.
Los resultados de DevSpeak no son confiables porque sus modelos sean más inteligentes que los de nadie. Son confiables porque cada capa del producto está construida para convertir un vacío en algo visible, en lugar de dejar que un modelo lo rellene con una suposición plausible. Este artículo recorre esas capas una por una.
Un motor, cuatro superficies, ningún stack supuesto
DevSpeak toma la forma en que una persona describe el trabajo de verdad ("necesitamos que el checkout deje de cobrar dos veces cuando la gente recarga la página") y devuelve una especificación estructurada sobre la que un desarrollador o un agente de programación con IA puede actuar. Puede ser una especificación técnica, un RFC, un conjunto de tickets de Jira, un diseño de API, un modelo de datos o un prompt.
Se distribuye en cuatro superficies, todas respaldadas por el mismo motor:
stdout para encadenarlos con el resto de tus herramientas.Como el motor es compartido, una especificación pedida desde la terminal sigue los mismos contratos que una pedida desde el editor. Las diferencias entre superficies son ergonómicas, no semánticas.
El motor también es deliberadamente agnóstico respecto a la tecnología. Reconoce los lenguajes y frameworks que muestra la evidencia disponible y escribe en sus modismos. Cuando no hay evidencia (ningún proyecto, ningún archivo adjunto, ningún stack mencionado en tu petición), no nombra ningún lenguaje, framework, base de datos ni plataforma de hosting. Una especificación que asume React y PostgreSQL en silencio, solo porque son estadísticamente comunes, es la primera forma de rellenar vacíos que esta arquitectura se niega a practicar.
Tres etapas, tres contratos que nunca se solapan
El núcleo del producto es un flujo de tres etapas. Solo la del medio es obligatoria. Lo que lo vuelve fiable no son tanto las etapas en sí como el hecho de que cada una tiene un contrato estrecho que no puede exceder.
Etapa 1 — Optimizar (opcional). Un pase de corrección monolingüe sobre tu texto de entrada. Corrige gramática, claridad y tono, y tiene prohibido cambiar el significado. En la práctica, conserva tu sujeto gramatical y tu voz ("necesitamos X" nunca se convierte en "se requiere X"), mantiene las mismas oraciones en el mismo orden, conserva cada nombre que mencionaste y se mantiene cerca de tu longitud original. Es determinista: la misma entrada produce la misma salida. Y como su resultado reemplaza el texto de tu editor, nunca responde una pregunta ni la formula. Una entrada con forma de pregunta vuelve como prosa mejor escrita, no como una respuesta. Si la edición no te convence, Deshacer restaura lo que escribiste.
Etapa 2 — Traducir (obligatoria). El motor que convierte la entrada en una especificación. Cuatro controles calibran el resultado:
Las mismas cuatro dimensiones están expuestas en la API pública. Una petición es un cuerpo JSON pequeño autenticado con la cabecera x-api-key:
`` curl -X POST https://www.devspeak.dev/api/v1/translate \ -H "x-api-key: $DEVSPEAK_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "input": "Stop charging people twice when they refresh the checkout page.", "audience": "Senior Dev", "context": "Backend", "format": "Technical Spec", "tone": 80 }'bash
`
Todos los planes pueden crear una clave API. GRATIS y VIBECODER incluyen 50 solicitudes a la API al mes con el modelo predeterminado; DEVELOPER y ENTERPRISE no tienen límite mensual de solicitudes.
Etapa 3 — Refinar (opcional). El refinamiento trabaja sobre el documento generado, no sobre tu entrada original. Envías el resultado anterior junto con comentarios concretos ("separa la migración en su propia sección", "la audiencia está de guardia, recorta el contexto") y DevSpeak devuelve un documento de reemplazo completo e independiente, no un parche. Tu entrada original viaja solo como referencia, así que un refinamiento puede ajustar la especificación sin derivar de vuelta hacia la redacción informal de la que partiste. El refinamiento iterativo está disponible en VIBECODER, DEVELOPER y ENTERPRISE.
Separar las etapas importa porque cada una evita un fallo concreto. Un corrector al que se le permite reinterpretar cambiará en silencio lo que pediste. Un traductor que además reescribe tu entrada hace imposible distinguir dónde terminó tu intención y dónde empezó la del modelo. Un refinador que vuelve a empezar desde la entrada cruda descarta cada corrección que ya hiciste.
El mundo cerrado es una función, no una limitación
Una especificación sobre una base de código existente falla de una forma característica. Todo lo que está visible en el contexto sale correcto, y todo lo invisible se inventa: un módulo auxiliar con nombre convincente, una variable de configuración que sigue la convención, una ruta que el proyecto nunca tuvo. La invención se lee exactamente igual que los hechos que la rodean, y eso es lo que la vuelve peligrosa.
DevSpeak lo aborda en tres partes.
Context Projects. Un Context Project vincula a tus traducciones instrucciones persistentes del proyecto, documentos e imágenes subidos y un conjunto fijo de conectores de recuperación (GitHub, Web Search y Context7), para que no tengas que volver a pegar el mismo contexto en cada petición. Con un repositorio de GitHub conectado, DevSpeak ordena los archivos del repositorio según lo que estás pidiendo y lee directamente el código relevante, en lugar de adivinar a partir de los nombres de archivo. Cada conector funciona con tu propia credencial (un token de acceso personal de GitHub, una clave de API de Context7 o una clave de Tavily para Web Search), y GitHub exige además un owner/repo mientras que Context7 necesita al menos un ID de biblioteca. Un conector al que le falte alguno de esos datos permanece desactivado y tu traducción se ancla igualmente sin él. Los Context Projects están disponibles en VIBECODER, DEVELOPER y ENTERPRISE. El [tutorial de anclaje en un Context Project](/tutorials/mcp/ground-translations-on-a-context-project) explica la configuración.
La regla de mundo cerrado. Cuando una traducción se ejecuta sobre contexto anclado, cualquier cosa ausente de ese contexto (un archivo, una ruta, una dependencia, una variable de entorno, un símbolo) se trata como inexistente. Suena restrictivo. Para quien lee la especificación es lo contrario, porque cambia el comportamiento por defecto del modelo de "inventa algo plausible" a "di que no está". Una especificación que dice "no se encontró un limitador de tasa existente; hay que introducir uno" es accionable. Una que extiende con total seguridad un limitador que no existe manda a alguien a una búsqueda que termina en confusión.
Procedencia, y la excepción de la propia regla. La recuperación no siempre tiene éxito. Un repositorio puede ser demasiado grande para leerlo completo, un conector puede agotar su tiempo, una página puede rechazar la descarga. DevSpeak lo informa en lugar de ocultarlo: el resultado anclado lleva la etiqueta Con contexto o Contexto parcial, para que sepas cuánto del proyecto vio realmente el motor. Cuando una fuente está incompleta, la regla de mundo cerrado se suspende para esa fuente, porque "no lo vi" ya no es evidencia de que "no existe". El motor registra una pregunta abierta en lugar de afirmar una cosa u otra.
El anclaje, además, falla de forma abierta. Si un conector no está disponible, igual recibes una especificación, solo que menos anclada, y la etiqueta te lo indica. La alternativa, negarse a traducir cada vez que una fuente falla, acostumbraría a la gente a dejar de usar el anclaje.
La incertidumbre va a cuarentena, no a la especificación
El anclaje cubre lo que el motor puede consultar. Mucho de lo que una especificación necesita no se puede consultar: el periodo de retención que nadie mencionó, si el cambio debe ser retrocompatible, quién decide un rollback. Un modelo presionado para producir un documento de aspecto completo responderá esas preguntas por su cuenta, en silencio, dentro del cuerpo de la especificación.
En el extremo detallado del control de tono, DevSpeak cierra ese camino. Cada formato de salida termina con una sección obligatoria de Supuestos y Preguntas Abiertas, y toda decisión que la entrada no especificó va allí en lugar de entrar en la especificación como si estuviera resuelta:
`markdown
Supuestos y Preguntas Abiertas
`
Es la sección más útil de un documento de DevSpeak, y la que la gente lee al final. Ahí encuentras la restricción que tenías en la cabeza y nunca escribiste. Un revisor puede responder una pregunta abierta en treinta segundos. Nadie puede revisar una decisión que se tomó de forma invisible tres párrafos antes.
La contrapartida merece decirse con claridad. En el extremo conciso del control, el motor hace una reescritura más ajustada y no añade esta sección. La salida concisa sirve cuando ya conoces las respuestas y quieres un documento compacto. Si no estás seguro de conocerlas, mueve el control hacia detallado.
XML cuando quien lee es una máquina
Markdown es el formato adecuado cuando una persona lee el resultado. Cuando lo lee un programa (una configuración de prompts, la definición de un agente, un esquema de datos que alimenta un paso de build), "casi bien formado" es un bug.
El Editor de Traducción te permite pedir XML determinista en lugar de Markdown, y la API pública acepta la misma opción mediante "responseFormat": "xml"`. Las respuestas XML se validan en el servidor antes de entregarse. El elemento raíz lo determina el formato que elegiste, así que un Modelo de Datos y un Diseño de API llegan con raíces predecibles y distintas. Si el resultado de un modelo se aparta de la estructura esperada, se repara o se envuelve de forma segura en lugar de entregártelo mal formado. La garantía es simple: lo que llega se puede parsear.
El límite honesto: bien formado no es lo mismo que correcto. La validación garantiza que tu parser no fallará. No garantiza que cada elemento diga lo que querías decir, y para eso existen la sección de Supuestos y el refinamiento.
Una conmutación que no deja de responder
Un producto que depende de un único proveedor de modelos hereda sus caídas como propias. La traducción gestionada de DevSpeak funciona sobre un conjunto curado de modelos. Si el modelo que atiende tu petición falla o se estanca, DevSpeak se recupera dentro de la misma petición, y recibes una especificación en lugar de un error.
Dos garantías hacen que esa recuperación sea fiable y no solo decorativa.
Un arranque lento no termina en un timeout. Cuando un modelo tarda en responder, la petición sigue diseñada para terminar con un documento en lugar de quedarse sin tiempo. Una redundancia que solo ayuda cuando el fallo es rápido no es una redundancia real.
Una respuesta vacía no es un éxito. Un modelo puede devolver una respuesta técnicamente exitosa sin nada dentro. DevSpeak está construido para que eso no te llegue: no recibes respuestas en blanco ni pagas por tokens que nunca ves. El detalle de ingeniería está en [Cómo construimos una pasarela de LLM agnóstica al proveedor](/blog/shipping-a-provider-agnostic-llm-gateway).
La contrapartida: cuando DevSpeak se recupera de esta forma, tu documento lo escribió un modelo distinto del habitual. Lo mismo vale para el enrutamiento automático: deja el selector de modelos en Auto y el servidor elige el modelo más adecuado por petición. Si quieres un modelo concreto, elígelo explícitamente en el selector de modelos. Y si prefieres usar una cuenta de proveedor que ya pagas, todos los planes, incluido el plan GRATIS, te permiten conectar tu propia clave.
Cada versión se conserva y ninguna se sobrescribe
Una especificación rara vez queda bien a la primera, y la segunda pasada no siempre mejora la primera. DevSpeak registra cada traducción, cada refinamiento y cada reversión como un snapshot inmutable en el historial del documento, con el modelo que lo produjo y si provino de una traducción, un refinamiento o una reversión.
Volver a una versión anterior tampoco reescribe el historial. Añade un snapshot nuevo que restaura el contenido anterior, de modo que el registro de lo ocurrido queda intacto. Puedes auditar cómo evolucionó una especificación, comparar versiones y volver al borrador previo a un refinamiento que se excedió, sin perder ese refinamiento.
Vale la pena mencionar una pequeña decisión de diseño porque muestra el mismo principio otra vez. Si un refinamiento tiene éxito pero guardarlo falla, DevSpeak igual devuelve el documento refinado y te avisa de que no se guardó. Descartar en silencio un trabajo que acabas de esperar sería un fallo oculto. Devolverlo con una advertencia es un fallo visible.
Lo que esta arquitectura no hace
Las capas anteriores reducen el detalle inventado. No lo eliminan, y este artículo sería engañoso si terminara sin decirlo.
El anclaje es tan bueno como el contexto. La regla de mundo cerrado vuelve honesto al motor sobre lo que vio. No puede hacer que un Context Project contenga lo que olvidaste conectar.
El modo conciso cambia transparencia por brevedad. Sin la sección de Supuestos y Preguntas Abiertas, las decisiones no declaradas quedan menos visibles. Esa elección la haces tú con el control, no el motor.
Una especificación no es un control de seguridad. DevSpeak vuelve explícitas las restricciones antes de que algo se ejecute. No es un sandbox, ni un límite de permisos, ni una revisión de código, y no sustituye a ninguno de ellos.
Lo que la arquitectura sí garantiza es más acotado y, en la práctica, más valioso: cuando DevSpeak no sabe algo, el documento lo dice en un lugar donde lo vas a ver.
Pruébalo con un requisito que ya tengas
La forma más rápida de entender el diseño es verlo encontrar un vacío en tu propia redacción. El plan GRATIS no requiere tarjeta de crédito. Una prueba de 30 días de VIBECODER, que añade refinamiento iterativo, Context Projects, instrucciones personalizadas y traducción de documentos, tampoco pide método de pago y vuelve al plan GRATIS al terminar sin ningún cargo.
Pega un requisito que normalmente le pasarías directo a un compañero o a un agente, lleva el tono a detallado y lee primero la sección de Supuestos y Preguntas Abiertas.