El ensayo de Carson Gross del 21 de septiembre de 2026 propone una nueva convención para la programación agéntica: almacenar Markdown seleccionado en un directorio `/src/md`, junto al código que ayuda a producir. Su afirmación central no es que la prosa sustituya literalmente a la implementación, sino que Markdown contiene cada vez más la intención que los prompts efímeros ocultan en la actualidad.
La propuesta trata Markdown como si fuera código fuente porque es texto plano, puede compararse mediante diferencias, es buscable, puede revisarse en solicitudes de cambios y lo gestionan de forma nativa tanto las personas como los modelos de lenguaje. Gross sugiere situar visiones generales de módulos, descripciones de funciones, notas sobre modelos de datos, notas sobre API y notas de infraestructura cerca del código correspondiente, mientras deja la documentación de procesos de nivel superior en sistemas como los rastreadores de incidencias o las wikis.
Asigna a las pruebas un papel de apoyo. Las pruebas deberían aportar una confirmación automatizada basada en Markdown, mientras que la prosa sigue siendo la explicación legible tanto para humanos como para agentes de lo que hace el sistema, por qué lo hace y qué no debe hacer. Esta división tiene la intención de facilitar la revisión de la intención sin obligar a convertir cada decisión de diseño en sintaxis de pruebas de bajo nivel.
El artículo es un argumento y una convención propuesta, no una prueba de que `/src/md` sea un estándar de ingeniería comprobado. Gross dice que no ha utilizado esta estructura de forma extensiva y espera que su forma de pensar cambie. También advierte de que Markdown necesita un “presupuesto de complejidad”, una curación cuidadosa y una sincronización ocasional con el código generado, incluidos los cambios que se revierten a la implementación.
La pregunta práctica es, por tanto, si los equipos deberían volcar todos los prompts en un repositorio. La cuestión es si una capa pequeña y mantenida de intención a nivel de código fuente puede reducir la ambigüedad sin convertirse en desorden obsoleto. El ensayo ofrece una respuesta útil: mantener Markdown cerca del código, hacerlo revisable y tratarlo como un artefacto vivo similar a una especificación, en vez de como una transcripción permanente de la generación de prompts.