- Un lenguaje de programación de próxima generación basado en LLM que puede reducir la base de código entre 5 y 10 veces
- En lugar de escribir código, el desarrollador redacta specs concisas, y el código se genera automáticamente con el comando
codespeak build
- Cuando cambian las specs, el sistema convierte la diferencia (diff) de la spec en una diferencia de código y la aplica
- También admite proyectos mixtos donde conviven código escrito manualmente y código generado, y en casos reales de código abierto se confirmó una mejora en la tasa de pruebas aprobadas
- Se enfoca en la ingeniería en equipo para manejar software complejo, y apunta a un entorno de desarrollo más amigable para las personas mediante mantenimiento centrado en specs
Descripción general de CodeSpeak
- CodeSpeak es un lenguaje de programación de próxima generación impulsado por LLM cuyo objetivo es reducir la base de código entre 5 y 10 veces
- Según la descripción del sitio, enfatiza la eficiencia con la frase “Shrink your codebase 5–10x”
- Este lenguaje es una herramienta para construir sistemas de nivel de producción, diseñada para proyectos de largo plazo y no solo para prototipos simples
- Sus usuarios objetivo son equipos de ingeniería que desarrollan software complejo; no busca el código experimental centrado en desarrolladores individuales, sino el desarrollo colaborativo
Desarrollo basado en specs
- El núcleo de CodeSpeak es la filosofía “Maintain Specs, Not Code”
- El desarrollador escribe specs concisas, y el código se genera automáticamente con el comando
codespeak build
- Si se modifica una spec, el sistema transforma automáticamente el cambio (diff) de la spec en un cambio (diff) de código
- Este enfoque resalta que mantener y gestionar specs es más fácil para las personas que mantener código
Soporte para proyectos mixtos
- CodeSpeak admite proyectos donde coexisten código manual existente y código generado
- Como ejemplo, se presenta un caso de un fork del repositorio MarkItDown de Microsoft
- Ofrece una guía tutorial para trabajar con proyectos mixtos por etapas
Función de conversión de código → spec (próximamente)
- CodeSpeak está preparando una función para analizar código existente y convertirlo en specs
- Con esto, será posible reemplazar partes del código existente por specs entre 5 y 10 veces más pequeñas
- Se enfatiza que el mantenimiento de specs es más amigable para las personas que el del código
Casos de estudio reales (Case Studies)
- CodeSpeak probó convertir código de varios proyectos de código abierto a specs
- Soporte de subtítulos WebVTT en yt-dlp: 255 LOC → 38 LOC, reducción de 6.7x, 37 pruebas agregadas
- Generador de SSN italiano en Faker: 165 LOC → 21 LOC, reducción de 7.9x, 13 pruebas agregadas
- Detección automática de codificación en beautifulsoup4: 826 LOC → 141 LOC, reducción de 5.9x, 25 pruebas agregadas
- Convertidor de EML→Markdown en markitdown: 139 LOC → 14 LOC, reducción de 9.9x, 27 pruebas agregadas
- En cada caso, la tasa de pruebas aprobadas se mantuvo o mejoró, mostrando la efectividad del enfoque basado en specs
Resumen
- CodeSpeak es un lenguaje de programación con IA centrado en specs que combina generación automática de código y eficiencia de mantenimiento
- Sus características principales son la generación de código basada en LLM, la sincronización spec-código y el soporte para proyectos mixtos
- En casos reales se demostró la reducción de código y la mejora en pruebas, lo que sugiere un posible aumento de productividad en la ingeniería de software en equipo
4 comentarios
No sé si llamarlo un lenguaje es puro bait o si de verdad ya vivimos en una época así.
> Como dijo Joel Spolsky en una charla en Yale, los intentos de "generar programas a partir de especificaciones" siempre han fracasado
> Si una especificación es lo suficientemente detallada como para definir completamente un programa, entonces escribir esa especificación es en sí tan difícil como programarlo
Aunque en principio estoy de acuerdo, también me parece algo obvio: igual que en la demostración de Gödel de que la completitud no existe desde el vamos, da la impresión de que se está criticando el intento partiendo de la suposición de que podría existir un producto completo.
Me recuerda a MDD (Model Driven Dev.).
Comentarios en Hacker News
Como dijo Joel Spolsky en una charla en Yale, los intentos de “generar programas a partir de una especificación (spec)” siempre han fracasado
si una especificación es tan detallada como para definir completamente un programa, entonces escribir esa especificación es en sí tan difícil como programarlo
Enlace a la charla original
ahora se pueden generar programas incluso con prompts incompletos, y consideran valiosa la investigación sobre cómo tratar los prompts de forma sistemática
la escalabilidad se está desplazando de agregar funciones a definir restricciones de comportamiento e invariantes estructurales
algo como “1. pedir información al usuario, 2. enviar una solicitud HTTP, 3. reportar si hay un error”,
y piensan que en ese caso simplemente es mucho más rápido y determinista escribir un script
Esto no es un lenguaje nuevo, sino un flujo de trabajo y herramientas para desarrollo basado en LLM
en lugar de código, se mantienen archivos de especificación en Markdown, y
codespeakmodifica el código con base en el diff de la especificaciónla ventaja es que los prompts quedan versionados junto con el código, y la desventaja es que la especificación no puede reflejar todos los detalles del código
están experimentando con una herramienta llamada
codespeak takeoverpara convertir código en especificaciones y reflejar los prompts de sesiones de agenteslo explican como un cambio del “modo sprint” de corto plazo al “modo maratón” de largo plazo
Entrada de blog relacionada
la idea es tan simple que cualquiera podría reimplementarla rápido, y esperan que una versión open source la reemplace pronto
proponen una política que permita “cambios menores”
en general, el concepto de un compilador incremental de pseudocódigo les parece interesante
creen que en 5 años no escribiremos código de esta manera, y que una especificación técnica al nivel del inglés será suficiente
Este enfoque es, más que un lenguaje, un tooling que mapea especificaciones a código
pero los modelos son no deterministas, así que incluso con la misma especificación pueden producir resultados distintos cada vez
una especificación es en esencia un resumen con gran pérdida de información, así que en bases de código grandes es difícil mantener la consistencia
lo que quisieran ver es un pipeline verificable de especificación en texto → especificación formal (formal spec) → código
lo importante no es el código en sí, sino la consistencia del comportamiento resultante
mientras más abstracta sea la especificación respecto al código, más implementaciones distintas son posibles, así que el determinismo sigue sin garantizarse
pienso que las pruebas automatizadas deberían cumplir el papel de la verdadera especificación
consideran que si se fija la seed, se puede obtener la misma salida para la misma entrada
Cursor y Antigravity están optimizados para el “vibe coding” centrado en humanos, pero Kiro está especializado en desarrollo basado en especificaciones centrado en agentes
usa formatos estructurados como EARS e INCOSE, y genera verificación automática de consistencia y pruebas basadas en propiedades (PBT)
si la especificación es sólida, la implementación prácticamente sigue sola
están ejecutando varios agentes CLI en paralelo para obtener resultados de alta calidad
El problema de un lenguaje formal de prompts no es la ambigüedad, sino la falta de capacidad del modelo para entender el contexto
incluso con el mismo prompt, el resultado cambia según el contexto
formalizar el prompt no sirve de mucho si el modelo entiende mal la base de código
como los modelos están optimizados para lenguaje conversacional, consideran que es mejor no usar directamente un lenguaje formal, salvo cuando haga falta
Expresan el deseo de que simplemente fuera posible transmitir intenciones a la computadora de forma determinista y formal
Este concepto parte de una premisa que entiende mal la estructura interna de los LLM
según investigaciones recientes, en los LLM existe una etapa de procesamiento separada entre la codificación y la decodificación,
y después del entrenamiento puede que el lenguaje en sí ya no sea tan importante
Enlace a la investigación relacionada
el objetivo es ayudar a las personas a expresar con claridad lo que quieren
No están seguros de que realmente se necesite una herramienta así
basta con escribir directamente una especificación en Markdown y pedirle al agente que genere el código
En “Prerequisites” del tutorial dice que se necesita una clave API de Anthropic
puede que sea una medida temporal por estar en versión alfa, pero se preguntan por qué hace falta usar la API
parece que también se podría inyectar directamente el prompt en una sesión como Claude Code
Enlace de referencia
Este proyecto les parece interesante porque es muy similar a una especificación de lenguaje para ejecutores de LLM en la que están trabajando
Mi proyecto AIL define y ejecuta cadenas de prompts basadas en YAML
la clave es tener un “motor de refinamiento de prompts” que convierta el lenguaje natural del usuario en instrucciones estructuradas
por ejemplo, analiza la intención del usuario, la divide en pasos y la optimiza según los estándares modernos de prompt engineering
con un interceptor así, sería posible un flujo como “convierte lo que acabo de decir al formato de CodeSpeak”
les parece una idea realmente genial y piensan explorarla a fondo