Cómo construí esta página
Esto no es mi biografía —esa vive en Sobre mí—. Esto es el detrás de cámaras: cómo se construyó el sitio que estás viendo. Y arranca con una confesión incómoda: no me gusta programar. Aun así, casi todo aquí está automatizado. ¿La trampa? Automatizar no es programar. Es pensar como Producto.
Todo empezó por flojera (de la buena)
Un blog personal no se muere por falta de ideas. Se muere por fricción: por el domingo en que ya no tienes ganas de redimensionar imágenes, pegar el HTML, revisar el SEO y programar la publicación. Si cada artículo cuesta una tarde de tareas aburridas, dejas de publicar. Punto.
Así que hice lo que haría con cualquier producto: identifiqué los pasos manuales que me daban flojera y los saqué del camino. No para escribir menos —eso sigue siendo mío— sino para que lo único que me cueste energía sea la idea, no la plomería.
Lo primero que construí no fue código: fueron las reglas
Antes de automatizar nada, escribí un documento con las reglas del proyecto. Quién soy, cómo escribo, qué no se toca. Suena a burocracia. Es exactamente lo contrario: es lo que evita tener la misma discusión cincuenta veces.
Digo “Producto”, nunca “PM”. Se confunde con Project Manager, y no es mi disciplina.
Cero cifras inventadas. Si un dato no tiene fuente verificable, no entra. Aunque quede bonito.
Ningún cliente se nombra. Las anécdotas se anonimizan siempre: “un banco”, “una dependencia de gobierno”. Las tecnologías sí se nombran.
Experiencia de campo antes que teoría. Primero el incidente real, después la definición. Es lo que hace que un artículo no huela a máquina.
Y lo que no sé, lo digo. Tengo cursos de Datadog, no manos en Datadog. Escribo sobre eso citando fuentes, no fingiendo cicatrices que no tengo.
Esa última regla es la que más me cuesta explicar y la que más protejo. En un mundo donde cualquiera puede generar mil palabras sobre cualquier cosa, lo único que no se puede falsificar es haber estado ahí.
El banco de trabajo: una IA para cada cosa
Aquí no hay una herramienta milagrosa. Hay varias, y elijo cada una como elegiría proveedores para un producto: por lo que resuelve, no por lo que está de moda.
OpenAI (API) → las imágenes finales de cada artículo, ya con el estilo definido.
Claude / Claude Code → escribir borradores, automatizar la publicación, auditar el sitio (SEO, velocidad en móvil, cazar errores) y conectar Google Analytics.
CapCut + IA → editar los videos de producto y la serie de mujeres.
Detrás de esas piezas, la fontanería: la API REST de WordPress para crear, programar y borrar sin entrar al panel; WPCode para los pedacitos de código que dan estructura; y Jetpack para el boletín por correo y el compartir automático en LinkedIn.
El pipeline: de idea a publicado
Lo interesante no es cada herramienta suelta, sino el orden en que pasan las cosas. Contado como lo vivo:
2. Sale un borrador completo: estructura, fuentes citadas, tono de siempre.
3. Yo lo reviso — esta parte no la delego, es mi voz.
4. Al aprobarlo: se generan las imágenes, se arma el formato, se publica o programa, se etiqueta, y se avisa a suscriptores y a LinkedIn.
Lo que antes era una tarde, ahora son minutos de revisión.
Cómo me entero de que algo se rompió antes que tú
Un sitio automatizado se rompe solo. Una imagen que no subió, un enlace que apunta a nada, un artículo programado que sale con el título mal. Nadie te avisa: simplemente se ve mal durante semanas hasta que alguien te lo dice.
Así que hay tres capas de revisión, y ninguna depende de que yo me acuerde:
2. Al abrir el proyecto. Si pasaron tres días o más sin revisar el sitio, me lo recuerda solo.
3. Cada lunes a las diez. Una tarea programada corre la revisión completa. Si la computadora estaba apagada, se recupera en cuanto la enciendo.
La revisión completa recorre todas las páginas del sitio, comprueba cada imagen una por una, sigue cada enlace interno, abre las páginas en un móvil simulado para cazar imágenes deformadas, y valida los artículos programados antes de que salgan. Si algo está roto, sale con nombre y apellido.
Mezclarlas era agotador: la lista jamás se vaciaba y todo parecía urgente. Separarlas convirtió una fuente de culpa en un tablero que se puede leer en diez segundos.
La parte que nadie enseña: la prueba y el error
Si todo esto suena limpio, es porque te cuento el final. El camino fue otra cosa.
Hubo imágenes que salían con un fondo cuadriculado horrible en vez de transparente. Un gato de la marca que en la compu se veía perfecto y en el celular salía casi transparente —una regla de opacidad escondida en el 16%—. Música de un video bloqueada por derechos de autor que tuve que rehacer. Y hasta formularios de suscripción que aparecían dos veces y en inglés donde no debían.
Los que de verdad enseñaron algo fueron estos cuatro:
.png mientras subía la versión .webp. Resultado: recuadros rotos en varios artículos, incluidos los ya programados. Lo peor no fue el error: fue que llevaba días ahí y nadie lo había visto.Las imágenes estiradas en el móvil. En la computadora se veían perfectas; en el celular, deformadas. Yo lo vi antes que la automatización, y eso fue justamente la señal de que faltaba una comprobación. Hoy existe: un navegador sin ventana abre las páginas a 390 píxeles de ancho y compara la proporción real de cada imagen contra la proporción con la que se está pintando.
La lista escrita a mano. El índice de biografías tenía los nombres tecleados uno por uno dentro del código. Se quedó en cinco cuando ya había once, y era invisible para el buscador. Ahora se genera solo desde la base de datos.
El aviso huérfano. Un artículo decía “imagen generada con IA” al final del texto, a media pantalla de distancia de la imagen que describía. Correcto de contenido, inútil de forma. La transparencia solo sirve si está pegada a lo que transparenta.
Hay un patrón ahí, y no es técnico: casi todos fueron cosas que “ya estaban listas”. Por eso ahora, cuando algo queda terminado, no digo que quedó bien. Digo el número: cero defectos. Un número se puede comprobar; “ya está todo listo” no.
Nada de eso venía en un tutorial. Se resolvió probando, viendo qué salía mal, y volviendo a probar. Esa tolerancia al error —saber que la primera versión va a estar fea y no rendirse ahí— es la habilidad más importante de todas. Y no es de programador: es de Producto.
Tres decisiones que valieron más que cualquier script
Automatizar es fácil de empezar y difícil de sostener. Estas tres son las que me han ahorrado más trabajo del que se ve.
Primero el taller, después la vitrina
Tuve la tentación de publicar sin parar y arreglar la plomería “después”. No lo hice. Cada artículo publicado sobre un sistema roto es un artículo que hay que volver a tocar a mano. Frenar dos semanas a dejar la base sana se paga solo en el primer mes. Optimizar también es avanzar, aunque no se vea en el calendario de publicaciones.
Que crecer no exija tocar el código
La regla de oro cuando no eres programadora: si añadir una categoría nueva obliga a editar código, el diseño está mal. Las categorías de la serie de video guardan su emoji en su propia descripción, dentro del panel de WordPress. Puedo inventarme “Piratas” o “Diplomáticas” a las once de la noche sin abrir un editor. La página se acomoda sola.
Y lo mismo con lo que se muestra
La portada de la serie mostraba todas las biografías. Con once ya era larga; con cien habría sido impasable. Hoy muestra cuatro —las dos últimas publicadas y las dos que vienen— y manda al índice completo, que sí está hecho para crecer. Casi ningún problema de diseño es de diseño: es de no haber preguntado “¿y cuando haya cien?”.
No terminó en el blog: marketing y video
Construir esto me empujó a terrenos nuevos. Aprendí marketing a la fuerza —de eso escribiré otro día— y hoy hago videos de producto, que edito en CapCut apoyándome en IA para acelerar. La misma lógica de siempre: entender el trabajo real, escoger la herramienta que lo resuelve, y no tenerle miedo a la primera versión imperfecta.
Si no programas y quieres hacer algo así
No necesitas aprender a programar. Necesitas aprender a describir bien lo que quieres, revisar el resultado con ojo crítico, y aguantar las primeras versiones feas sin tirar la toalla. La IA no reemplaza el criterio: lo amplifica. Si no sabes qué quieres, te da algo genérico rapidísimo. Si sabes exactamente qué buscas —como cuando defines un producto—, se vuelve una palanca enorme.
Si me preguntas qué es lo que en realidad delego, no es escribir. Es acordarme de verificar. La máquina revisa mejor que yo porque no se cansa, no se aburre y no da nada por hecho. Lo que decide qué se publica, con qué voz y bajo qué reglas sigue siendo mío, y ahí no pienso ceder nada.
Este blog es mi laboratorio. Cada cosa que ves —el boletín, las imágenes, hasta la huella de gato del footer— salió de una conversación, una API y unas cuantas vueltas de prueba y error.
Si llegaste hasta acá, gracias por la curiosidad. Es exactamente lo que mueve todo esto.
Que los sistemas estén con ustedes. ✦