El 20 de septiembre de 2026, tras una semana de silencio operativo, el proyecto PrensaBot volvió a encenderse. Pero la reactivación no fue un simple retorno a la normalidad. El primer objetivo práctico—escribir una entrada para el propio blog del proyecto—chocó de frente con una limitación fundamental del software: no existía una forma nativa de redactar un borrador manual. El sistema, diseñado para consumir y transformar cables de noticias RSS, le exigía a su propio creador una fuente externa para poder funcionar.
El problema del "dogfooding": cuando tu herramienta te complica la vida
Esta situación puso en evidencia el principio del "dogfooding" (usar tu propio producto). La necesidad concreta de generar contenido conceptual sobre el desarrollo del bot, sin un feed de noticias que lo avale, reveló una brecha en la arquitectura. Inicialmente, se probó simular un feed RSS local con el texto deseado, pero la solución era incómoda y poco elegante. La herramienta, en esencia, estaba forzando un flujo de trabajo ajeno a la necesidad real de su usuario principal.
Nace la Redacción Directa: borradores manuales y pulido con IA
La respuesta fue el desarrollo rápido, en horas, de una nueva funcionalidad core: la Redacción Directa. Esta extensión introduce un nuevo tipo de origen para los artículos (direct_draft), que se suma al ya existente (scraped_feed). La especificación técnica permitió:
-
Ingresar apuntes y borradores libres de texto directamente en una interfaz dedicada.
-
Elección del periodista virtual y de la categoría de destino en WordPress.
-
Opción de "Pulir con IA" para que el modelo refine el texto, o "Publicar As-Is" para respetar íntegramente el draft del autor.
En paralelo, se calibró y puso a punto el soporte para multi-categoría remota en WordPress, asegurando que los artículos pudieran clasificarse correctamente al publicarse.
El aprendizaje implacable de construir con lo que se vende
El episodio dejó una lección clara, confirmada en el hilo interno de desarrollo del 20 de septiembre: el dogfooding es el radar de producto más certero. Si una funcionalidad resulta incómoda o restrictiva para el equipo creador, con alta probabilidad será un punto de fricción para los clientes finales. La reactivación no fue solo volver a poner en marcha servidores, sino un proceso de introspección técnica que derivó en una mejora concreta impulsada por una necesidad real. La pausa operativa, lejos de ser tiempo perdido, permitió un enfoque fresco que identificó y resolvió una limitación estructural.
Deja una respuesta