El código que no se escribe: CodeSpeak y la revolución de las especificaciones
Hay nombres que en el mundo de la programación tienen un peso específico. Andrey Breslav es uno de ellos. Si hoy millones de desarrolladores de Android escriben código en Kotlin en lugar de Java, es en gran parte gracias a él: Breslav es el diseñador principal del lenguaje que JetBrains lanzó en 2011 y que Google adoptó oficialmente como lenguaje preferido para Android en 2017, durante el Google I/O que cambió el ecosistema móvil para siempre. No es un académico que teoriza desde una cátedra: es uno de los que han construido herramientas utilizadas cada día por cientos de miles de personas en el mundo real, con todos los compromisos, los fallos de producción y las presiones que esto conlleva.
Esta premisa no es un homenaje por sí mismo. Sirve para entender por qué su nuevo proyecto, CodeSpeak, merece atención mucho más allá de los límites de los habituales avances de lenguajes experimentales que proliferan en GitHub. Cuando Breslav dice que quiere replantear la forma en que los seres humanos interactúan con el código en la era de los agentes de IA, lo hace con el bagaje de quien ya ha recorrido una vez este camino y sabe dónde se esconden las trampas. Como contó a Gergely Orosz en el podcast de Pragmatic Engineer, la lección más profunda de Kotlin no trata sobre la sintaxis o el sistema de tipos, sino sobre la interoperabilidad: un lenguaje nuevo que no logra convivir pacíficamente con lo que ya existe está destinado a seguir siendo un experimento. Es un principio que ha trasladado directamente a CodeSpeak.
El proyecto está en Alpha Preview, detalle que vale la pena tener en cuenta a lo largo de toda la lectura, y está construido en torno a una idea que, dicha en una línea, suena casi provocadora: ¿y si dejáramos de mantener el código y empezáramos a mantener las especificaciones?
Especificaciones, no código: un cambio de paradigma
Para entender qué propone CodeSpeak, primero hay que dar un paso atrás y observar el problema que intenta resolver. Cualquiera que haya trabajado en un proyecto de software de complejidad media conoce la sensación: el código crece. Crece cuando se añaden funcionalidades, crece cuando se corrigen errores, crece cuando llegan nuevos desarrolladores que interpretan las especificaciones de forma ligeramente diferente a quienes les precedieron. Con la llegada de los agentes de IA que generan miles de líneas en pocos segundos, este crecimiento corre el riesgo de volverse incontrolable. No porque el código generado sea necesariamente incorrecto, sino porque ya nadie logra mantenerlo todo en la cabeza.
El terreno sobre el que se asienta CodeSpeak no es neutro. En febrero de 2025, Andrej Karpathy, cofundador de OpenAI y exdirector de IA de Tesla, acuñó la expresión "vibe coding" para describir una práctica ya muy extendida: dar instrucciones en lenguaje natural a un agente de IA y aceptar el código generado sin leerlo realmente, confiando en el instinto de que "funciona". El post original en X recogió millones de visualizaciones en pocos días, y la etiqueta entró incluso en el diccionario Merriam-Webster para marzo del mismo año, una velocidad que dice mucho sobre lo real que ya era el fenómeno. CodeSpeak nace exactamente como respuesta estructurada a esta deriva: no niega que los LLM puedan escribir código útil, pero sostiene que dejar a los agentes libres para generar sin vínculos formales produce bases de código que ya nadie entiende realmente.
CodeSpeak propone desplazar el foco: en lugar de escribir y mantener el código de implementación, el equipo mantiene archivos de especificación, documentos compactos, legibles por un ser humano, escritos en un Markdown estructurado con una sintaxis propia. El sistema se encarga entonces de traducir esas especificaciones en código funcional, utilizando un modelo de lenguaje (actualmente Claude de Anthropic, lo que explica el requisito de una clave API) como motor de generación.
La analogía más útil, para quienes no escriben código, es la de los planos técnicos en arquitectura. Un arquitecto no construye el edificio ladrillo a ladrillo: dibuja los planos, especifica los materiales, define las proporciones y las cargas. Los obreros o, en este caso, el LLM, se encargan de la ejecución concreta. Cuando el arquitecto quiere modificar la disposición de una habitación, no demuele y reconstruye: actualiza los planos y la obra se adapta. CodeSpeak funciona exactamente así: se modifica la especificación, se lanza codespeak build y el código se actualiza en consecuencia.
Este enfoque se inserta en un debate más amplio que en el mundo del desarrollo de software recibe varios nombres: spec-driven development, intent-based programming o, más genéricamente, la idea de que el próximo nivel de abstracción no son nuevos lenguajes de programación en el sentido tradicional, sino nuevas formas de comunicar la intención a los agentes de IA. La diferencia respecto al simple "prompt engineering" (dar instrucciones a un chatbot) es que CodeSpeak introduce estructura, versionamiento y testabilidad. Las especificaciones viven en un repositorio Git, se rastrean como cualquier otro artefacto de código y su efecto se mide a través de las suites de pruebas existentes. No es vibe coding: es ingeniería de software con un nivel de abstracción más alto.
Cómo funciona: de la CLI al takeover
Técnicamente, CodeSpeak se instala con un único comando de terminal, uv tool install codespeak-cli, y requiere una clave API de Anthropic que el usuario aporta (el modelo es BYOK, Bring Your Own Key). A partir de ahí, el flujo de trabajo se articula en tres modalidades principales, pensadas para escenarios diferentes.
La modalidad más sencilla es la que parte de cero (greenfield): se inicializa un proyecto CodeSpeak, se escriben las especificaciones en archivos Markdown con extensión .cs.md, se lanza codespeak build y el sistema genera el código Python correspondiente, ejecuta las pruebas y señala si todo funciona. Una especificación para una aplicación de línea de comandos para gestionar notas podría ocupar literalmente diez líneas de texto legible y producir una aplicación funcional completa con comandos, gestión de almacenamiento e interfaz de terminal.
La modalidad más interesante, y la que tiene más implicaciones prácticas para quienes trabajan en proyectos existentes, es la mixed mode. CodeSpeak no pide tirar el código que ya existe: puede convivir con él. Se inicializa con codespeak init --mixed y, desde ese momento, el proyecto se vuelve híbrido: algunas partes siguen siendo escritas a mano por los desarrolladores y otras son gestionadas por las especificaciones. El LLM "ve" ambas partes durante la generación y puede usar el código manual como contexto para implementar correctamente las especificaciones. Es un compromiso pragmático que recuerda, no por casualidad, a la elección de Kotlin de garantizar la interoperabilidad completa con Java desde el primer día.
El tercer escenario, introducido recientemente con el comando codespeak takeover, es quizás el más sugerente: dado un archivo de código existente, incluso legado, incluso escrito hace años por otra persona, CodeSpeak lee el código fuente y extrae automáticamente una especificación compacta. A partir de ese momento, para modificar ese componente ya no se toca el código Python (o cualquier otro lenguaje): se modifica la especificación y se relanza la construcción. En la entrada oficial del blog que ilustra esta funcionalidad, el equipo utilizó como conejillo de indias el proyecto de código abierto MarkItDown de Microsoft, un conversor de documentos a Markdown, tomando el archivo responsable de la conversión de los archivos .msg de Outlook, extrayendo una especificación de unas pocas decenas de líneas y luego usando esa especificación para corregir un error real reportado en GitHub. Todo ello sin tocar una sola línea de Python. La modificación de la especificación —añadir soporte para los campos Cc, Bcc, Fecha y archivos adjuntos faltantes— fue de 23 líneas; el código generado resultante fue de 221 líneas. Una relación de aproximadamente 10 a 1.
Modularidad: cuando las especificaciones se convierten en un sistema
Un lenguaje que solo funciona para proyectos pequeños es un experimento de laboratorio. Para convertirse en una herramienta profesional, debe escalar. Y aquí es donde entran en juego las funciones de modularidad que el equipo lanzó el 9 de marzo de 2026 con la versión 0.3.4: las spec dependencies y los managed files.
La idea de las dependencias de especificaciones es análoga a la de los módulos en el código tradicional: una especificación puede declarar que depende de otra mediante una simple directiva en el frontmatter del archivo Markdown. Si la especificación de la interfaz de línea de comandos de una aplicación depende de la especificación de la capa de almacenamiento de datos, CodeSpeak construye primero la capa de almacenamiento y luego la interfaz, garantizando que esta última pueda usar correctamente lo que la primera proporciona. Y si solo se modifica la especificación del almacenamiento (cambiando, por ejemplo, el backend de JSON a SQLite con una sola línea de texto), CodeSpeak reconstruye solo esa parte, sin tocar el resto.
Los managed files son, en cambio, un mecanismo de gobernanza: cada especificación "sabe" qué archivos de código están bajo su responsabilidad. Cuando durante una construcción CodeSpeak necesita modificar un archivo que no pertenece a la especificación actual —por ejemplo, el archivo de configuración de dependencias del proyecto—, lo hace, pero avisa explícitamente al desarrollador. Toda la lógica recuerda a la distinción entre propiedad y acceso en los sistemas de control de acceso: cada especificación tiene su dominio y las invasiones de campo se señalan, no se toleran silenciosamente. Para equipos que trabajan en bases de código grandes y complejas, es una garantía no trivial contra los efectos secundarios no deseados de las modificaciones.
Los números: ¿cuánto se reduce realmente el código?
Los casos de estudio publicados en el sitio oficial son el elemento más concreto y verificable de toda la propuesta. El equipo tomó cuatro proyectos reales de código abierto, no ejemplos de juguete construidos ad hoc, y generó las especificaciones correspondientes para partes significativas de su código, midiendo la reducción en términos de líneas.
Para yt-dlp, el célebre descargador de vídeos, el componente para la gestión de subtítulos WebVTT pasó de 255 líneas de código a 38 líneas de especificación, con un factor de reducción de 6,7 veces. Para Faker, la librería de Python para generar datos ficticios, el generador de códigos fiscales italianos bajó de 165 a 21 líneas (7,9 veces). Para BeautifulSoup4, la librería para el análisis de HTML, el módulo de detección automática de codificación es el caso más imponente: 826 líneas de código reducidas a 141 de especificación, factor 5,9. Y para MarkItDown, el conversor de Microsoft ya citado, el módulo EML pasó de 139 a 14 líneas, con un factor de 9,9, casi 10 veces.
El dato que más impresiona que los números absolutos, sin embargo, es el relativo a las pruebas. En los cuatro casos, la suite de pruebas no solo siguió pasando tras la regeneración del código, sino que vio aumentar el número de pruebas que se superan con éxito: 37 pruebas añadidas para yt-dlp, 13 para Faker, 25 para BeautifulSoup4, 27 para MarkItDown. La reducción del código no es cosmética, no se trata de comprimir el código fuente eliminando comentarios y espacios en blanco, sino de eliminar la redundancia conceptual dejando que el LLM se encargue de los detalles de implementación que son, como los llama Breslav, "obvios para las máquinas". Lo que queda en la especificación es solo lo que es específico del dominio: las reglas de negocio, las elecciones arquitectónicas, los casos límite.
Dicho esto, es honesto señalar un límite metodológico: estas pruebas han sido realizadas por el propio equipo de CodeSpeak en partes seleccionadas de proyectos de código abierto. No se trata de comparativas independientes en bases de código arbitrarias. La pregunta de cómo se comporta el sistema en código especialmente intrincado, con dependencias circulares o lógica distribuida entre muchos archivos, queda por ahora sin una respuesta documentada.
¿Más humanos o menos humanos?
Existe una tentación recurrente, cuando se habla de herramientas de IA para el desarrollo de software, de caer en una de las dos trampas simétricas: o el triunfalismo ("la IA lo hará todo, los programadores están obsoletos") o el negacionismo ("es solo un autocompletado glorificado, nada nuevo bajo el sol"). CodeSpeak no se presta bien a ninguna de las dos narrativas, y este es probablemente su rasgo más interesante.
Para entender cómo se sitúa respecto a las herramientas ya existentes, vale la pena hacer una comparación directa. GitHub Copilot y sus análogos, Cursor, Junie de JetBrains y la galaxia de asistentes integrados en los IDE, operan sobre el código como artefacto primario: sugieren líneas, completan funciones, a veces generan bloques enteros. Son herramientas extraordinariamente útiles, pero su modelo conceptual no cambia: el desarrollador escribe código, la IA ayuda a escribir código más rápido. Los agentes de IA más recientes, como Claude Code o los flujos de trabajo "LLM + herramientas" que están proliferando, dan un paso más: pueden navegar por archivos, ejecutar comandos, abrir pull requests. Pero incluso en este caso, el artefacto que producen y modifican es el código, y el código generado por agentes autónomos que se automodifican es, como Breslav subrayó explícitamente en el podcast con el Pragmatic Engineer, una fuente de opacidad creciente. ¿Quién controla qué, cuando algo deja de funcionar?
CodeSpeak responde a esta pregunta con una elección radical: quitar el código generado del centro de la atención humana y poner en su lugar las especificaciones. El LLM no es un asistente que sugiere, es un compilador que ejecuta. La diferencia no es solo semántica: cambia profundamente el contrato entre desarrollador y máquina. El desarrollador no revisa el código generado línea por línea (actividad que, en salidas de cientos de líneas producidas en segundos, es en la práctica a menudo ilusoria); revisa la especificación, que es compacta, legible y versionada en Git como cualquier otro documento. El código generado es, en esta visión, un artefacto intermedio, similar al bytecode de Java o al ensamblador producido por un compilador de C: algo que en principio se puede inspeccionar, pero que en la práctica diaria no es el punto donde se concentra el pensamiento.
Esto tiene implicaciones concretas en el flujo de trabajo de los equipos. En un proyecto CodeSpeak maduro, los responsables de producto y los líderes técnicos razonan en términos de especificaciones ejecutables, documentos que describen qué debe hacer el sistema, no cómo lo hace. Los desarrolladores cuidan la calidad de estas especificaciones y de las pruebas asociadas más que el detalle de cada función individual. Las revisiones de código se desplazan: en lugar de comentar sobre nombres de variables y elecciones de implementación, se discute si la especificación captura correctamente el comportamiento esperado. Es un salto conceptual no trivial, similar, por usar una comparación del mundo del diseño, al paso del dibujo a mano alzada a los sistemas de diseño paramétrico: ya no se dibuja cada elemento, se definen las reglas que lo generan.
Sin embargo, hay una cuestión que los defensores más entusiastas tienden a pasar por alto: ¿es la especificación realmente más legible y comprensible que el código? Para funciones sencillas y bien delimitadas, la respuesta es casi con seguridad sí. Pero para lógicas complejas, con dependencias sutiles entre componentes y comportamientos que surgen de la interacción de muchas partes, la especificación corre el riesgo de convertirse ella misma en un documento denso y difícil de mantener. Se desplaza el problema más que resolverlo, y el riesgo es que la complejidad, eliminada del código, se reinstale en la especificación en formas menos estructuradas y, por tanto, más difíciles de razonar. Es la misma crítica que se ha dirigido a los sistemas low-code y no-code a lo largo de la última década: la abstracción no elimina la complejidad, la oculta, y cuando resurge, lo hace en lugares donde las herramientas para gestionarla son más escasas.
Lock-in, riesgos y preguntas abiertas
Ser honesto sobre un proyecto en Alpha Preview significa también rendir cuentas con lo que todavía no funciona, o que podría no funcionar nunca de la forma esperada. CodeSpeak plantea una serie de cuestiones legítimas que vale la pena abordar sin rodeos.
El primer riesgo es el del bloqueo tecnológico (lock-in). Adoptar CodeSpeak significa confiar en un lenguaje propietario, en una cadena de herramientas específica y en un proveedor de LLM (actualmente Anthropic) para la generación del código. Si mañana el proyecto cambia de dirección, la empresa que lo desarrolla cierra o el modelo de precios de la API de Anthropic se vuelve insostenible, ¿qué pasa con el código generado? Técnicamente, el código Python (o cualquier otro lenguaje de destino) sigue existiendo y es legible, no se pierde el producto del trabajo. Pero se pierde la capacidad de mantenerlo a través de las especificaciones, lo que significa volver al punto de partida, con la dificultad añadida de trabajar sobre un código que no ha sido escrito a mano y que podría tener estructuras no obvias.
El segundo riesgo se refiere a la ambigüedad de las especificaciones. Un compilador tradicional es determinista: dado el mismo código fuente, siempre produce el mismo resultado. Un LLM no lo es. Dos construcciones sucesivas de la misma especificación pueden producir código funcionalmente equivalente pero estructuralmente diferente, lo que complica la depuración, el versionamiento y la comprensión de qué ha cambiado y por qué. El equipo de CodeSpeak ha introducido las pruebas como mecanismo de estabilización (si las pruebas pasan, el código es correcto por definición), pero esto requiere una suite de pruebas suficientemente completa y bien diseñada. En proyectos donde las pruebas escasean o están mal escritas —y son muchos más de los que se admite—, el sistema pierde uno de sus principales salvavidas.
El tercer riesgo es el de la depuración opaca. Cuando el código generado no se comporta como describe la especificación, ¿dónde se busca el problema? ¿En la especificación (ambigua), en el modelo (que ha interpretado mal), en la versión de la API (cambiada silenciosamente), en el contexto del proyecto (que el LLM ha leído parcialmente)? La cadena causal se alarga y, con ella, el tiempo necesario para aislar y corregir el error. El equipo señala esto como uno de los frentes de mejora prioritarios en su hoja de ruta, pero por ahora es un límite real que cualquiera que quiera usar CodeSpeak en producción debe tener en cuenta.
Finalmente, está la cuestión de la portabilidad. CodeSpeak soporta hoy Python, y solo Python. La extensión a otros lenguajes está en la hoja de ruta, pero aún no tiene fecha. Para la gran mayoría de los proyectos empresariales, que usan Java, TypeScript, Go o pilas políglotas, esta es una barrera de entrada significativa.
Dicho esto, sería injusto usar estos límites para descartar el proyecto. Son los límites normales de una Alfa, no defectos estructurales de la idea. La pregunta más interesante no es "¿funciona perfectamente ahora?" —la respuesta es obviamente no—, sino "¿la idea aguanta bajo presión?". Y aquí la respuesta es menos obvia y más interesante.
Hoja de ruta y perspectivas
La hoja de ruta pública que emerge de las entradas del blog es bastante clara en sus prioridades. El tema de la modularidad, introducido con las dependencias de especificaciones y los archivos gestionados en marzo de 2026, es el principal frente de trabajo: hacer que las especificaciones sean componibles y reutilizables es el requisito previo para escalar a proyectos de dimensiones reales. El codespeak takeover está en fase de perfeccionamiento: el objetivo declarado es garantizar que la especificación extraída del código existente sea lo suficientemente completa como para poder regenerar una implementación equivalente desde cero, pasando todas las pruebas originales. Todavía no hay anuncios sobre soporte para lenguajes más allá de Python, ni sobre integraciones con sistemas de CI/CD.
La pregunta estratégica de fondo es si CodeSpeak puede aspirar a convertirse en un estándar de facto para lo que algunos ya llaman "programación nativa de IA", el diseño de lenguajes y herramientas pensados desde el principio para un mundo en el que parte de la ejecución se delega en modelos de lenguaje, o si seguirá siendo una herramienta de nicho, adoptada por equipos con una altísima disciplina de pruebas y casos de uso bien delimitados. La respuesta dependerá en parte de la calidad de la ejecución, en parte de la evolución de los modelos subyacentes y en parte de factores del ecosistema que hoy son difíciles de predecir.
Breslav tiene una posición clara sobre el contexto más amplio. En su diálogo con el Pragmatic Engineer, afirmó que 2026 será el año del renacimiento de los entornos de desarrollo integrados frente a las herramientas de terminal, no por nostalgia, sino porque los agentes de IA trabajan mejor dentro de entornos estructurados que ofrecen un contexto rico. Es una previsión que se alinea perfectamente con la filosofía de CodeSpeak: no el prompt libre en el vacío, sino la intención humana canalizada en estructuras que la máquina puede interpretar de forma fiable.
El oficio que cambia
Hay una pregunta que sobrevuela todo esto y que va más allá de las consideraciones técnicas: ¿qué ocurre con el trabajo de los desarrolladores en un mundo donde una herramienta como CodeSpeak funciona bien?
La respuesta superficial, y la más común en las redes sociales, es que los programadores se vuelven obsoletos. Breslav la rechaza explícitamente con una frase que vale la pena citar en su totalidad: "En el futuro, seguirán siendo los ingenieros quienes construyan sistemas complejos. Tenedlo en cuenta: no es que vayamos a desaparecer todos en el aire." No es optimismo de fachada: es la misma lógica que ha guiado cada salto de abstracción en la historia de la informática. El ensamblador no eliminó a los programadores; el C no eliminó a los programadores; los lenguajes de alto nivel no eliminaron a los programadores. Cambiaron lo que hacen, desplazando el centro de gravedad del trabajo desde la gestión de los detalles mecánicos hasta el modelado conceptual del problema.
CodeSpeak, si cumple sus promesas, desplaza aún más este centro de gravedad. Menos tiempo escribiendo código repetitivo (boilerplate), más tiempo razonando sobre qué debe hacer el sistema, diseñando las pruebas que verifican su comportamiento, escribiendo especificaciones que sean precisas sin ser rígidas. Es un trabajo más cercano al de un arquitecto de software que al de un artesano del código y, históricamente, este tipo de transición ha creado más valor del que ha destruido, aunque haya redistribuido roles y competencias de forma no indolora.
El riesgo real no es la desaparición del programador: es la concentración de las oportunidades. Si mantener un sistema complejo requiere solo una décima parte de las líneas de código, quizás también requiera menos desarrolladores para mantenerlo. La eficiencia ganada por los equipos más disciplinados podría traducirse en presiones sobre el tamaño de las plantillas, al menos a corto plazo. Es la clásica paradoja de la productividad tecnológica: crea riqueza en el agregado, pero la distribuye de forma asimétrica en el transitorio.
Para los desarrolladores más jóvenes hay, además, una cuestión de aprendizaje. Aprender a programar escribiendo código, con todos los errores, los depuradores abiertos a las tres de la mañana, la lenta comprensión de cómo funciona realmente la memoria o el trabajo en red, es un camino formativo que tiene su propia lógica. Un mundo en el que el código se genera a partir de especificaciones corre el riesgo de oscurecer estos niveles de comprensión. No es un problema irresoluble —los médicos también aprenden anatomía aunque ya no realicen intervenciones a mano desnuda—, pero es una cuestión que el sector deberá abordar conscientemente, no dejar que se resuelva sola.
Una lengua para humanos y máquinas
Volviendo a donde habíamos empezado, al perfil de Breslav y a las lecciones de Kotlin, hay un hilo conductor que atraviesa toda la historia de CodeSpeak y que vale la pena hacer explícito. Kotlin nació, entre otras cosas, de la constatación de que Java se estancaba: el lenguaje no evolucionaba a la velocidad requerida por los desarrolladores y el mercado estaba listo para algo mejor. CodeSpeak nace de una constatación análoga, pero invertida: los lenguajes existentes evolucionan demasiado lento respecto a la velocidad con la que los agentes de IA están cambiando la forma en que se produce el código. No se trata de un lenguaje más ergonómico para los humanos, se trata del primer lenguaje diseñado explícitamente para un sistema en el que humanos y LLM colaboran, cada uno haciendo la parte para la que es más apto.
Si esta apuesta sale bien, CodeSpeak podría representar algo más que una herramienta útil: podría ser el primer ejemplo de una nueva categoría, la de los lenguajes "nativos de IA", diseñados desde el principio para un mundo en el que la generación automática de código no sea una excepción sino la norma. Si no sale bien, por límites técnicos, de adopción o porque la evolución de los propios modelos haga obsoleto el enfoque, seguirá siendo en cualquier caso un experimento valioso que habrá aclarado cuáles son las preguntas correctas que hay que hacerse.
Breslav cierra su entrevista con una invitación que suena más a desafío: "No hay que creer ciegamente todo lo que se lee en Twitter: algunas personas afirman cosas absurdas. Sin embargo, si se utilizan correctamente, estas herramientas pueden ser muy productivas y vale absolutamente la pena invertir en ellas." Es el tono de quien ya ha atravesado un ciclo de expectación (hype), el de Kotlin, y sabe que entre el entusiasmo inicial y la utilidad duradera siempre hay un tramo de camino difícil de recorrer. CodeSpeak está al principio de ese tramo. Vale la pena seguirlo.