Realizo desarrollos para empresas medianas, y en los últimos meses me estoy encontrando una situación que se repite. Desde que el equipo usa IA para programar salen muchos más cambios que antes, se ha acelerado la creación de código inmensamente. Sin embargo, la forma de llevarlos a producción no ha cambiado nada: alguien hace un svn update o un git pull en el servidor y repasa de memoria lo que hay que hacer antes y después.
No escribo esto contra la IA, porque yo también la uso a diario. Lo escribo porque ha dejado a la vista un problema que estas empresas arrastraban desde hace años y que, con el ritmo de antes, se podía ir capeando.
Y no es un problema solo de empresas pequeñas. He trabajado en consultoras grandes que tenían todo esto resuelto hace tiempo: integración continua, revisiones de código, entornos de preproducción y un proceso de despliegue que no dependía de la memoria de nadie. Aun así, la IA les está obligando a adaptarse también a ellas, porque esos procesos estaban dimensionados para el ritmo al que escribe código una persona. Si incluso quien ya tenía los procesos tiene que replantearlos, quien no los tenía lo nota mucho más.
Lo que me encuentro
El escenario suele ser parecido. Es una empresa mediana con un equipo de desarrollo reducido, y su forma de trabajar se parece más a un waterfall que a otra cosa, aunque las tareas vivan en un tablero Kanban o similar. Esté el código en Subversion o en Git, he visto equipos con GitHub o GitLab que siguen subiendo directamente a la rama principal, sin pull requests, con un pipeline que nadie mira o sin pipeline, y desplegando a mano igual que con SVN. Tener la herramienta no es usarla. Tampoco hay tests automáticos. La documentación que hay en el repositorio la escribió alguien hace tiempo y nadie la ha vuelto a tocar.
Al desplegar, aparecen las cosas que no están en el código:
- una variable de entorno nueva que hay que dar de alta en el servidor.
- una consulta que se ejecuta antes de subir, y otra después para comprobar la integridad de los datos.
- una migración de base de datos que alguien lanza a mano.
- una Lambda que también hay que actualizar, o que hay que ejecutar una vez.
Lo que más me ha llamado la atención es otra cosa. Quien despliega no siempre ha mirado las tareas que está desplegando. Ni hay ningún paso del proceso que le obligue a hacerlo. Sube lo que hay en el repositorio, y lo que esas tareas necesitaban para funcionar depende de que alguien se acuerde de avisarle o de que se lea un comentario sobre la tarea en el tablero.
Dos casos recientes
El primero es de esta misma semana. Se subieron cambios y, de repente, algo dejó de funcionar. Revisamos lo que había cambiado y nada en el código podía provocar ese fallo. La única explicación que encontramos fue de tiempos: durante el despliegue convivieron código antiguo y código nuevo. En ese proyecto hay migraciones y Lambdas de mantenimiento que se ejecutan de forma periódica, y lo más probable es que alguna se lanzara justo en ese hueco, con su código o el de la aplicación todavía en la versión anterior. No podemos asegurarlo al cien por cien, y eso es precisamente lo preocupante: nadie tenía apuntado qué se ejecuta solo, cuándo, ni en qué orden había que actualizar cada pieza.
El segundo es de otra empresa, que trabaja con Subversion sin ramas: todo el mundo sube a la misma línea, y a veces se suben cambios a medias, con parte de los archivos olvidados en la copia local de quien hizo el commit. Cuando termino un desarrollo para ellos, siempre hago lo mismo antes de subir nada: actualizo desde Subversion, compilo, pruebo lo que he desarrollado, ajusto si hace falta y, si funciona, hago el commit. Pero si en el repositorio faltan archivos de otra persona, el build falla, o tengo que esperar a que alguien los suba. Y el caso peor es el contrario: que el build pase, que el despliegue también, y que algo explote en producción sin que nadie se haya dado cuenta.
Ninguno de los dos es un problema de código. Los dos son problemas de proceso.
Por qué la IA lo empeora sin tener la culpa
Antes, la propia lentitud hacía de control sin que nadie lo pretendiera. Si una persona tardaba una semana en sacar una funcionalidad, tenía tiempo de saber qué tocaba, y el despliegue de esa semana llevaba dos o tres cambios que todo el mundo conocía.
Ahora, en esa misma semana entran muchos más cambios, y cada uno puede traer su propio requisito de despliegue. Además, con el código generado pasa algo nuevo: el desarrollador puede aceptar un cambio que lee una variable de entorno nueva o que da por hecha una columna que no existe, sin haberse quedado con ese detalle. Lo sabía el código, pero la persona no lo tenía en la cabeza, y menos aún el que despliega.
Así que el cuello de botella se ha movido. Escribir el código ha dejado de ser lo lento. La pregunta ahora es cuántos cambios podemos llevar a producción sabiendo lo que hacemos.
El problema de fondo: lo que hace falta para desplegar no está escrito en ningún sitio
La tarea del tablero dice qué se ha hecho: «Añadir autenticación con el proveedor nuevo». Lo que no dice es cómo se despliega: si hay que crear una tabla, qué variable falta en producción o qué hay que comprobar después. Esa información está en la cabeza de quien hizo la tarea o en un mensaje que se perdió hace dos semanas.
Hay una pregunta que uso como prueba: ¿dónde está escrito qué hay que hacer para desplegar esta tarea? Si la respuesta es «pregúntale a tal persona», el proceso depende de que esa persona esté y se acuerde. Y el día que falta o se le olvida un paso, el problema aparece en producción.
Lo que propongo, por orden y sin cambiar de herramientas
La buena noticia es que las empresas pequeñas pueden aprovechar los mismos flujos que usan las grandes, adaptados a su tamaño. Y gracias a la IA, implantarlos es mucho más sencillo que antes: el pipeline, el script de comprobación o la configuración de las migraciones son justo el tipo de código que la IA escribe bien y que antes nadie tenía tiempo de preparar.
No hace falta migrar a Git si estás en Subversion, ni cambiar de plataforma si ya usas GitHub o GitLab, ni montar Kubernetes para empezar. Lo que les propongo a estas empresas, en este orden, es lo siguiente.
1. Notas de despliegue en cada tarjeta
Es lo más sencillo y lo que más cambia. Cada tarjeta del Kanban lleva una plantilla fija, que rellena quien hace la tarea:
NOTAS DE DESPLIEGUE
¿Migración o SQL? no / sí → cuál y cuándo (antes o después)
¿Variables de entorno? no / sí → nombre y en qué entornos
¿Lambdas u otros servicios? no / sí → cuál y qué hay que hacer
¿Procesos programados? no / sí → cuáles; ¿se paran mientras se despliega?
¿Cómo se comprueba? qué mirar en producción después de subir
¿Cómo se deshace? qué hacer si algo sale malLa regla es que la tarjeta no pasa a «Listo para desplegar» sin la plantilla rellena, aunque en todas las respuestas ponga «no». Escribir «no» también es información, porque significa que alguien se lo ha preguntado.
2. Una release, no un puñado de tarjetas
Quien despliega no debería tener que recorrer el tablero. Antes de cada despliegue se junta en un único documento lo que sube y lo que piden sus notas:
RELEASE 2026-10-08
Tareas: PROJ-1842, PROJ-1847, BUG-921
Antes: variable PAYMENT_API_URL en producción
Durante: migración de la tabla customers
actualizar la Lambda de notificaciones
Después: login, alta de cliente de prueba, /health
Si falla: volver a la revisión anterior; la migración no borra datosEl desarrollador trabaja con tareas; quien despliega, con releases. Ese documento es además lo que, dentro de un mes, te dice qué se subió un martes cualquiera.
3. Que el repositorio sepa a qué tarea pertenece cada cambio
Una convención sencilla: todo cambio lleva el identificador de la tarea. Cómo se consigue depende del repositorio.
Con Git, lo natural es que cada tarea vaya en su rama y entre en la principal mediante una pull request (merge request en GitLab) con el id en el título. La rama principal se protege para que nadie suba directamente, y la revisión de la pull request es el momento de preguntar por las notas de despliegue. GitHub y GitLab lo traen de serie; solo hay que activarlo.
Con Subversion, para que no dependa de la buena voluntad, un hook pre-commit en el servidor rechaza los commits cuyo mensaje no empiece por el id:
#!/bin/sh
REPOS="$1"
TXN="$2"
svnlook log -t "$TXN" "$REPOS" | grep -qE '^[A-Z]+-[0-9]+' || {
echo "El mensaje tiene que empezar por el id de la tarea (PROJ-123)." >&2
exit 1
}Y antes de cada commit, svn status: los archivos marcados con ? no están bajo control de versiones. Si alguno es tuyo, falta en el commit. Es el segundo caso de arriba, resuelto con un comando.
A partir de ahí, svn log entre dos revisiones, o git log entre dos etiquetas, te da la lista de tareas que entran en un despliegue, y la release se puede comprobar contra ella. Si sale una tarea que nadie había apuntado, mejor verlo antes de desplegar que después.
4. Las migraciones, en una herramienta y no en un correo
«Antes de subir, ejecuta esta SQL» es probablemente la instrucción que más sustos da. Herramientas como Flyway o Liquibase guardan las migraciones como archivos versionados junto al código y registran en una tabla de la propia base de datos cuáles se han aplicado (flyway_schema_history en Flyway, DATABASECHANGELOG en Liquibase). Así no hay que acordarse de qué se ha ejecutado en cada entorno, porque la base de datos lo sabe.
Y, por lo que contaba en el primer caso, conviene que cada migración funcione también con la versión anterior del código, porque durante el despliegue van a convivir. Si una columna cambia de nombre, primero se añade la nueva; la versión siguiente deja de usar la antigua, y solo después se borra. Así da igual qué pieza se actualice antes, o qué proceso programado se ejecute en medio.
5. Comprobar la configuración antes de tocar nada
El clásico: todo funciona en desarrollo y en producción falla porque faltaba una variable. Un script de veinte líneas que se ejecuta antes del despliegue y lo para si falta algo evita media hora de buscar el error:
#!/bin/bash
for v in PAYMENT_API_URL NOTIFICATION_QUEUE_URL DB_URL; do
if [ -z "${!v}" ]; then
echo "Falta $v: no se despliega." >&2
exit 1
fi
done
echo "Configuración completa."Es mucho mejor que el despliegue no empiece que descubrir el fallo con producción a medias.
6. Unas pocas comprobaciones después, siempre las mismas
No hace falta una batería de tests para empezar. Basta con tres o cuatro comprobaciones de humo, siempre las mismas: que responde /health, que se puede iniciar sesión y que la operación principal funciona. Primero como lista en la release, y cuando sea posible, como script.
7. Y entonces, automatizar
Cuando lo anterior funciona a mano, es el momento de llevarlo a un pipeline que compile, ejecute el script de variables, aplique las migraciones, despliegue y lance las comprobaciones. La herramienta depende de dónde esté el código: si usas GitHub o GitLab, GitHub Actions o GitLab CI ya vienen incluidos y no hay que instalar nada; con Subversion, Jenkins trabaja con él sin problema. Aunque solo compile, un pipeline que se ejecuta con cada commit ya merece la pena: si alguien deja archivos sin subir, el aviso le llega a él en minutos, y no a la siguiente persona que actualice. Automatizar un proceso que todavía no está escrito solo sirve para equivocarse más rápido. Primero se escribe y luego se automatiza.
La IA, también del lado del despliegue
Si la IA ha acelerado los cambios, lo lógico es que ayude también a controlarlos. Y aquí le veo mucho recorrido, más allá de escribir código.
Para empezar, ayuda a montar todo lo anterior. Escribir el pipeline, el hook, el script de variables o las primeras migraciones era trabajo que en un equipo pequeño siempre quedaba para «cuando haya tiempo», y con la IA se hace en una tarde. Revisándolo, claro.
También sirve para revisar lo que va a subir. Un uso que estoy probando con empresas más antiguas con SVN, y que me parece de los más interesantes, es pasarle el diff (svn diff -r 1200:1215, o git diff main...rama en Git) y pedirle que liste lo que ese cambio necesita para desplegarse: variables de entorno que se leen por primera vez, tablas o columnas nuevas, llamadas a servicios externos, cambios en una API, procesos programados afectados. Si encuentra una variable nueva que nadie ha apuntado en la tarjeta, ahí hay una conversación pendiente antes de subir.
Y el paso siguiente es que todo esto no dependa de que alguien se acuerde de pedírselo. Las herramientas de IA para desarrollo ya permiten empaquetar un procedimiento en una skill, unas instrucciones que la IA sigue siempre igual: qué leer, qué preguntar y qué plantilla rellenar. O encargárselo a un agente especializado. Es algo que ya uso en mis proyectos personales, donde tengo el control sobre cómo se hacen las cosas, y es donde he comprobado que funciona. Con skills y agentes, los pasos de este artículo se pueden automatizar también:
- Notas de despliegue. Al cerrar una tarea, una skill lee el diff y la tarjeta, rellena la plantilla y marca lo que no cuadra: una variable que el código lee y la tarjeta no menciona, una migración sin plan de vuelta atrás.
- Documento de la release. Antes de desplegar, junta las notas de todas las tareas que entran, las ordena en antes, durante y después, y las contrasta con el
svn logo elgit logpara avisar si sube algo que no está en el tablero. - Revisión previa. Un agente repasa la release completa con la lista de comprobaciones y deja escrito qué ha verificado y qué no ha podido verificar.
Lo que no cambia es quién decide. La IA prepara, contrasta y avisa; la decisión de desplegar y la responsabilidad siguen siendo de una persona. Bien usada, la IA no sustituye ese control, sino que le quita el trabajo tedioso que hacía que nadie lo hiciera.
Lo que no haría
No empezaría cambiando de herramientas. Si ya usas Git, el problema no es Git: es no usar lo que la plataforma ya ofrece. Y si estás en Subversion, migrar a Git, implantar Scrum o montar un clúster puede tener sentido más adelante, pero en un equipo pequeño que ya va justo, meter todo eso a la vez suele acabar en un proceso nuevo que nadie sigue, junto al antiguo, que sigue funcionando por debajo.
Lo que funciona es lo poco y constante: la plantilla en la tarjeta, la release escrita y la regla en el repositorio, sea un hook o una rama protegida. Son cosas que se pueden implantar en una semana y que cambian la pregunta de «¿alguien se acuerda de lo que había que hacer?» a «¿dónde lo pone?».
Para cerrar
Durante años el objetivo era programar más rápido, y ya lo estamos consiguiendo. Pero un cambio no está terminado cuando se escribe, sino cuando está en producción, se ha comprobado que funciona y se sabe cómo deshacerlo.
Si tu equipo se reconoce en lo que he contado, mi consejo es empezar por la plantilla de notas de despliegue en las tarjetas.