Extender una herramienta blog-a-newsletter con un agente

Resumen

Este artículo describe un caso práctico: cómo un agente de código (Claude Code) realizó una modificación precisa en una herramienta propia que convierte entradas de un blog en boletines por email. El autor necesitaba incorporar un nuevo tipo de contenido, llamado “beats”, y con un prompt breve y ciertas instrucciones de validación obtuvo exactamente el cambio esperado. Más allá de la anécdota, el ejemplo muestra patrones útiles para equipos técnicos que quieran delegar tareas de ingeniería rutinarias a agentes automáticos.

Qué es la herramienta y el nuevo requisito

La herramienta es una aplicación HTML/JavaScript que obtiene las últimas entradas desde una instancia de Datasette y genera HTML enriquecido que se pega en el editor de Substack. En otras palabras: Substack se usa aquí como un canal de distribución por correo para las entradas del blog.

Recientemente se introdujo un nuevo tipo de contenido en el blog, denominado “beats”. Los beats agrupan publicaciones cortas o registros sobre lanzamientos, herramientas, visitas a museos y otros contenidos externos. Muchas de estas entradas son automáticas o poco relevantes (por ejemplo, una corrección menor en un proyecto), pero el sistema permite añadir descripciones adicionales que actúan como un filtro de interés: si un beat lleva una nota o comentario, se considera que vale la pena incluirlo en el feed.

El objetivo fue que la herramienta blog-a-newsletter incluyera esos beats con descripción, replicando la lógica ya usada para el feed Atom del sitio.

Diseñando el prompt para el agente

La estrategia de prompting fue deliberadamente concisa pero con referencias útiles:

Indicar al agente que clonara el repositorio simonw/simonwillisonblog en /tmp para referencia. Esa instrucción ayuda al agente a inspeccionar el código real (modelo, esquema, definiciones) sin arriesgarse a mezclar ese código en commits posteriores.
Señalar explícitamente qué archivo modificar: blog-to-newsletter.html. En repositorios grandes, referenciar el archivo exacto dirige al agente hacia el objetivo entre cientos de aplicaciones.
Explicar la lógica de negocio: incluir beats que tienen descripciones, de forma similar al feed Atom del blog. Esta pequeña regla evita tener que describir el esquema o la consulta SQL en detalle.
Pedir validación automática: iniciar un servidor estático con python -m http.server y usar la ayuda de una herramienta de automatización (uvx rodney —help) para verificar que la salida del newsletter en la herramienta coincida con la página principal del blog.

Esas cuatro piezas (código de referencia, archivo destino, regla de negocio y test de validación) conforman un patrón potente para asignar cambios de código a agentes: dar contexto real, objetivo claro, criterio de selección y forma de comprobar la corrección.

Por qué las instrucciones de validación importan

Los agentes de código son más confiables cuando pueden correr pruebas simples por sí mismos. En este caso se pidió usar un servidor HTTP local en lugar de servir archivos desde disco, porque algunas llamadas fetch fallan cuando la app se abre como archivo en el navegador. Además, el autor aprovechó una técnica de automatización —Rodney instalado vía uvx— cuya salida de —help está diseñada para enseñar a los agentes cómo usar esa herramienta. La comparación entre la salida generada por la app y la página principal del blog fue la métrica para aceptar el cambio.

Resultado técnico que generó el agente

El pull request que produjo el agente hizo justo lo necesario: extendió la consulta que junta contenido del blog con una nueva cláusula UNION que incluye beats con nota y no en borrador. La parte relevante de la consulta quedó, en esencia, así:

... union all
select id, 'beat' as type, title, created, slug, 'No HTML' as html,
  json_object(
    'created', date(created),
    'beat_type', beat_type,
    'title', title,
    'url', url,
    'commentary', commentary,
    'note', note
  ) as json,
  url as external_url
from blog_beat
where coalesce(note, '') != '' and is_draft = 0
union all ...

Además, el agente generó un mapeo en JavaScript para mostrar los tipos formales de beat, que coincide con lo definido en el modelo Django leído por el agente:

const beatTypeDisplay = {
  release: 'Release',
  til: 'TIL',
  til_update: 'TIL updated',
  research: 'Research',
  tool: 'Tool',
  museum: 'Museum'
};

Es notable que el agente leyó la base de código, dedujo la lógica de negocio y produjo cambios coherentes y probados.

Lecciones prácticas para equipos técnicos (incluido LatAm)

Referencias reales acortan prompts: Permitir al agente inspeccionar el código hace innecesario describir estructuras complejas. Clonar a un directorio temporal (/tmp) evita contaminación accidental.
Indiquen un método de validación: Los agentes se benefician de pruebas simples y automáticas. Si su herramienta depende de fetch o de rutas relativas, probarla con un servidor local evita falsos negativos.
Capitalicen en convenciones del proyecto: El agente usó la definición del ORM para construir mapeos de tipos. Mantener modelos claros y nombrado consistente facilita la automatización.
Empiecen con cambios pequeños y bien definidos: Añadir una cláusula UNION o una ruta nueva es una tarea acotada; es un buen primer paso para construir confianza en agentes de código.
Consideren la infraestructura disponible: En contextos de Latinoamérica, donde a veces hay limitaciones de conectividad o políticas de seguridad, prefieran workflows que permitan clonar repositorios y validar localmente sin depender de servicios externos.

Cómo aplicar este patrón en su organización

Definan tareas repetitivas o rutinarias (ajustes de UI, consultas, mapeos) que sean seguras para delegar.
Acompañen cada tarea con un criterio de aceptación automatizable (tests, comparación de salidas, servidor local). Esto reduce la necesidad de supervisión humana constante.
Mantengan documentación y estructuras de códigobién definidas (modelos, constantes, rutas) para que los agentes encuentren la información necesaria.
Empiecen con permisos limitados: utilicen ramas y PRs para revisar los cambios antes de fusionarlos en producción.

Conclusión

El ejemplo demuestra que un prompt breve y foco en la validación permite a un agente de código implementar un cambio concreto con precisión. Más allá de la curiosidad técnica, el patrón es práctico para equipos que quieran acelerar tareas de ingeniería rutinarias: dar contexto real, especificar el artefacto a modificar, expresar la regla de negocio y proveer una manera automática de comprobar resultados. Para equipos en Latinoamérica, adoptar este enfoque puede ahorrar tiempo y liberar recursos para trabajo estratégico, siempre que se acompañe con buenas prácticas de revisión y pruebas locales.