Entrada de demostración. Está publicada para ver cómo queda el blog con contenido real:
tabla, código, listas y cita. Se borra cuando ya no haga falta. Lleva noindex y no
aparece en el sitemap.
Los despliegues de viernes tienen mala fama por una razón que casi nunca se dice en voz alta: no
falla el código, falla la memoria de quien despliega. A las seis de la tarde, con prisa por cerrar,
nadie recuerda si el feature flag está apagado, si la migración es reversible o si el backup de
las cuatro es el bueno.
Así que dejamos de confiar en que alguien se acordara y escribimos la lista. No es una lista de
deseos: cada punto es una comprobación que devuelve sí o no, y un no detiene el despliegue sin
discusión.
down y se ha probado en el entorno de staging de esta semana, no del mes
pasado.El presupuesto de error convierte una discusión de opiniones en una resta. Antes de la lista, decidir si un despliegue «urgía» dependía de quién hablaba más alto en el canal. Ahora es un número:
| Situación | Presupuesto | Decisión |
|---|---|---|
| Mes tranquilo, sin incidentes | 100 % disponible | Se despliega |
| Un incidente Sev-2 ya consumido | ~35 % | Se despliega con vigilancia |
| Dos incidentes y un Sev-1 | 0 % | Se congela todo hasta cerrar la causa |
Nadie discute una tabla. Y cuando alguien quiere saltársela, la conversación ya no es «creo que podemos», es «¿qué vas a quitar de la tabla y por qué?», que es una pregunta mucho más incómoda de responder.
La lista vive en el repositorio y corre sola antes de cada release. Lo importante no es el script: es que si falla, el despliegue no sigue.
def listo_para_desplegar(slo, flags, migracion):
"""Devuelve (bool, motivos). Un solo 'no' bloquea el release."""
motivos = []
if slo["presupuesto_restante"] <= 0:
motivos.append("sin presupuesto de error: se congela el release")
if not flags["apagados_en_produccion"]:
motivos.append("hay flags activos: el cambio no es reversible al instante")
if not migracion["tiene_down"] or not migracion["probada_esta_semana"]:
motivos.append("migración sin 'down' probado esta semana")
return (len(motivos) == 0, motivos)
Cuarenta líneas y un if. No hace falta una plataforma: hace falta que el if esté en el camino
crítico y no en un wiki que nadie abre.
Una checklist no existe para que la gente se acuerde de las cosas. Existe para que no pueda fingir que se acordó.
No arregla el código malo, ni la falta de tests, ni que el equipo vaya con prisa porque el backlog está mal priorizado. Lo que hace es que el error se cometa con los ojos abiertos y quede en el registro: quién desplegó, a qué hora y con qué comprobaciones en verde. Cuando algo se tuerce, la revisión empieza por datos y no por recuerdos.
Este texto es una demostración del formato del blog: tabla, código con resaltado, cita y lista numerada. El contenido es inventado para la prueba.
]]>La mayoría de blogs que usan IA esconder ese detalle, o lo esconden tan bien que da igual. La alternativa no es confesar culpas: es dar información. Un artículo que un modelo redactó entero y nadie verificó no vale lo mismo que uno escrito desde la experiencia y revisado línea a línea. Si etiqueto, el lector decide. Si no etiqueto, decido yo por él, y eso es peor.
Un envase no te dice si el contenido es bueno, pero te dice qué lleva. Con un texto pasa lo mismo: saber que un modelo propuso la estructura ya te dice algo útil sobre lo que tienes delante, sin quitarle mérito al resultado.
Así que cada entrada lleva dos cosas. Arriba, junto a la fecha, un nivel de un vistazo. Al pie, una ficha de autoría que desglosa el proceso fase por fase: idea, estructura, código, redacción, verificación.
El Nivel 2 y el Nivel 3 se confunden a menudo, y no son lo mismo. La diferencia no es cuánta IA se usó, sino de quién es el texto. En el Nivel 3 la IA es una herramienta de corrección. En el Nivel 2 la estructura del artículo nació de una conversación con el modelo, aunque después reescriba todo lo que se publica.
El blog es Markdown servido por Jekyll en GitHub Pages. No hay base de datos, ni panel, ni servicio
de terceros: escribir es crear un fichero y hacer git push. La etiqueta son cuatro campos en el
frontmatter, y la tabla se genera desde ellos.
---
layout: post
title: "Cómo etiqueto lo que escribo cuando hay un modelo detrás"
date: 2026-10-18 10:00:00 +0200
permalink: /blog/como-etiqueto-lo-que-escribo/
ia_nivel: 2
ia_humano_pct: 85
ia_fases:
- fase: "💡 Idea y perspectiva"
quien: humano
detalle: "Decisión personal, basada en cómo trabajo a diario."
- fase: "✍️ Redacción y tono"
quien: hibrido
detalle: "Borrador inicial con IA; reescritura completa a mano."
---
La plantilla recorre ia_fases y pinta la tabla; el nivel se convierte en una insignia de color con
su enlace a esta explicación. Como el dato vive en los metadatos y no en el cuerpo del texto, no
puede desincronizarse de la entrada: si alguien cambia la ficha, cambia el frontmatter, y el cambio
queda en el historial de git con fecha y autor.
La etiqueta declara un proceso, no lo garantiza. Nadie audita que mi Nivel 1 sea realmente Nivel 1. Es un compromiso público, y por eso funciona: si mañana publico aquí un texto generado entero y lo etiqueto como Nivel 1, cualquiera puede señalarlo. La transparencia útil no es la que se demuestra con un sello de calidad, sino la que se puede contradecir.
]]>