Simon Willison montó su página de newsletters por voz: Codex y GPT-6 Astra en una hora

Simon Willison, creador de Django y uno de los profesionales más visibles en el desarrollo con LLM, ha publicado en su blog la página Newsletters: un índice de todas sus newsletters, tanto la semanal gratuita en Substack como la mensual para patrocinadores. Casi todo el código lo escribió el modelo GPT-6 Astra High en el modo de voz de Codex, dentro de la aplicación de escritorio de ChatGPT. El dictado duró cerca de media hora, mientras Willison preparaba la cena. Otra media hora se fue en revisar y retocar con el teclado.

Media hora junto a los fogones

Empezó la sesión con un comando de texto: «Start dev server and open in browser». Así apareció en pantalla la vista previa local del blog y pudo seguir el avance de forma visual. Después pulsó «Start new voice chat». Ese botón no es el del micrófono: es el que está justo a su derecha. Colocó el portátil en la cocina y se puso a trabajar.

La tarea era típica de Django: un modelo nuevo, una migración, una view, plantillas y varias funciones de importación. Willison confiaba en que el modelo lo resolvería, así que planteó el encargo de forma coloquial, con «eh…» y autocorrecciones.

Primero dijo que las newsletters no hacían falta en las páginas de etiquetas, en el índice ni en los archivos por fecha, y luego cambió de idea sobre las fechas: si la newsletter salió el 19 de septiembre, debe aparecer en la página de ese día. Las copias de Substack no deben indexarse en las búsquedas, porque duplican contenido del blog. Las ediciones mensuales, en cambio, tienen contenido único y, cuando se abren un mes después del envío, deben aparecer en las búsquedas.

El modelo entendió los requisitos; Willison publicó la transcripción completa en un Gist. De vez en cuando hacía preguntas aclaratorias y volvía a editar el código.

Qué salió de la sesión

Durante la sesión se construyó lo siguiente:

• un nuevo modelo de Django, su migración y la configuración del panel de administración;
• cuatro importaciones: las ediciones recientes de Substack vía RSS, el resto del archivo de Substack mediante una API no documentada, las ediciones mensuales publicadas desde un repositorio de GitHub y la última edición cerrada para patrocinadores desde un repositorio privado;
• las páginas públicas /newsletters/ y /newsletters/2026/;
• la aparición de las newsletters en las páginas de días y meses, pero no en la portada ni en las etiquetas;
• enlaces: las ediciones semanales llevan a Substack y las mensuales tienen páginas propias;
• integración con el buscador del sitio.

Con la API de Substack, el modelo se las arregló solo. Conocía la ruta /api/v1/archive y la probó directamente. Después lanzó una búsqueda para entender la paginación y encontró un artículo de Karen Spinner. El diseño de la página índice también lo ideó el modelo. Willison lo ajustó por voz, mirando la vista previa desde el otro lado de la cocina.

Las importaciones quedaron sin terminar. Astra propuso exportar los datos de la copia local y subirlos a producción, pero el autor quería un mecanismo como el de sus otros scripts. Parte de los datos está en un repositorio privado de GitHub, así que hacía falta una nueva clave de API, y para eso había que sentarse al teclado.

Revisión y límites de la voz

Lo siguiente siguió el esquema habitual: Codex creó una rama y abrió un pull request, y Willison leyó el diff en la interfaz de GitHub. La principal objeción fue que, en una de las importaciones, el modelo llamaba a Git mediante subprocess. Para un repositorio privado, la API es más fiable, así que pasó al texto y pidió sustituir el enfoque. Los commits adicionales del PR n.º 719 incluyen ese cambio y pequeños ajustes de visualización. Otra media hora de prompts de texto y el código llegó a producción.

La conclusión principal del autor es sorprendentemente sobria: la voz no se convertirá para él en una herramienta diaria. A OpenAI le gusta mostrar demos así, por ejemplo en el DevDay, y allí funcionan. Pero cuando se llega a los detalles, es más rápido pegar un ejemplo o un mensaje de error, o seleccionar el fragmento de código que interesa, que describirlos con palabras. A eso se suma la oficina compartida: no hablaría así con el ordenador delante de sus compañeros.

La fortaleza de esta combinación está en otra parte. La vista previa visual y la posibilidad de pasar al teclado en cualquier momento hacen que el modo de voz resulte bastante más útil que en el teléfono durante un paseo con el perro, donde salen sobre todo investigación y brainstorming. La conclusión práctica para los desarrolladores es esta: la voz sirve para una primera pasada, en la que hay que explicar la intención y la estructura general.

El pulido, la revisión y todo lo que dependa de código exacto conviene hacerlo por texto. La tarea con la que probar el enfoque debe ser típica: un framework conocido, un esquema de datos claro y un servidor local que dé respuesta inmediata. Y la revisión del pull request sigue siendo obligatoria: fue ella la que detectó la llamada innecesaria a Git.