Módulo 6: Promoción, rollback y entrega documentada

3. Revisar cambios como diffs, incluida la IA

Siguiente →

Descripción

Al terminar esta lección vas a poder revisar cualquier cambio de un workflow antes de que llegue a producción, leyendo su diff —la lista exacta de qué cambió— con criterio, no a ojo. Vas a entender qué es un pull request y por qué es el punto de revisión obligatorio de un cambio, y vas a saber revisar algo nuevo y delicado: workflows que una IA creó o modificó dentro de tu instancia. El principio que vas a instalar es corto y no se negocia: la IA propone, Git registra, el humano aprueba el diff antes de que el cambio llegue a prod.

Esto importa porque promover sin revisar es prometer sin leer. En la lección 2 viste que la promoción segura empieza con "revisaste el diff de lo que estás promoviendo". Esta lección es ese paso, en detalle. Y llega en un momento particular de la historia: n8n 2.0 permite que asistentes de IA construyan y editen workflows dentro de tu instancia. Eso multiplica la cantidad de cambios que pasan por tus manos y hace la revisión más importante, no menos: cuando una máquina puede generar veinte cambios en una tarde, el humano que revisa el diff es la última —y a veces la única— línea entre una buena idea y un desastre en producción.

Conexión con el módulo: la lección 2 movió el cambio hacia adelante (promover); esta pone el control de calidad antes de ese movimiento. Aquí usas el diff limpio que la normalización del Módulo 3 te dejó legible, y preparas el terreno para la lección 4, donde una IA de verdad va a construir workflows contra un entorno no-prod. Esta lección responde la pregunta que la lección 4 vuelve urgente: si una IA tocó el workflow, ¿cómo sé que no rompió nada antes de promoverlo? La respuesta es la misma revisión de diff que aplicas a cualquier cambio, con un par de cuidados extra que aquí aprendes.

Qué es un diff, y por qué es tu herramienta de revisión

Ya viste diffs en el Módulo 2, pero vale la pena definir bien la palabra, porque es la protagonista de esta lección.

Un diff —de difference, diferencia— es la lista exacta de qué cambió entre dos versiones de un archivo: qué líneas se agregaron, cuáles se quitaron, cuáles se modificaron. No es el archivo entero; es solo lo que se movió. Git te lo muestra con un formato visual que se lee de un vistazo: las líneas que se agregaron van con un + y suelen aparecer en verde, las que se quitaron con un - y en rojo, y lo que no cambió aparece en gris, como contexto.

Piénsalo como el juego de "encuentra las diferencias" entre dos dibujos casi idénticos. En vez de describirte los dos dibujos completos, el diff te señala directamente: "aquí, este árbol que antes no estaba; allá, esta nube que desapareció". Te ahorra comparar todo para encontrar lo que se movió. Cuando revisas un cambio de order-triage, no lees los cientos de líneas del JSON entero: lees las tres que el diff resalta, y sabes exactamente qué se está proponiendo.

El comando que ya conoces lo produce:

git diff HEAD~1 workflows/order-triage.json

Esto te muestra qué cambió en order-triage.json entre la versión anterior (HEAD~1, "un commit antes de la punta") y la actual. Es la misma herramienta de la lección 4 del Módulo 2, ahora al servicio de una decisión de peso: aprobar o no un cambio antes de que toque producción.

Por qué la normalización del Módulo 3 hace posible esta revisión

Detente un momento en algo que en el Módulo 3 fue esfuerzo y aquí es recompensa. Si el JSON de tus workflows no estuviera normalizado —campos volátiles quitados, claves ordenadas, formato legible con --pretty—, el diff sería ilegible. Un cambio de una línea aparecería enterrado entre decenas de líneas de ruido: un versionId que cambió solo, un meta.instanceId distinto, las claves reordenadas al azar. Revisar eso sería imposible, y la revisión moriría por inútil.

Por eso el Módulo 3 insistió tanto en la normalización: no era pulcritud por la pulcritud, era construir el cimiento de la revisión. Un diff limpio es lo que hace que un humano pueda revisar de verdad. Cuando en el ejemplo de la lección 2 el diff mostraba "solo el umbral, 5000, y nada más", ese "y nada más" es el regalo de la normalización. Guárdate esta conexión: la disciplina de limpiar el JSON y la disciplina de revisar el cambio son la misma disciplina, separadas por tres módulos.

El pull request: el punto de revisión obligatorio

Ahora subamos un escalón. El git diff en tu terminal es la herramienta; el pull request es el ritual que la vuelve una práctica de equipo.

Un pull request —"solicitud de incorporación", a menudo abreviado PR— es una propuesta formal de cambio que dice: "quiero que estos cambios entren a la rama principal; por favor, revísenlos antes". Vive en GitHub (o en plataformas parecidas), muestra el diff completo de la propuesta, y le da a otra persona —o a ti mismo, con calma, otro día— un lugar para aprobar o pedir cambios antes de que la propuesta se integre. Nada llega a la rama principal sin pasar por ahí.

Piénsalo como el control de calidad al final de una línea de producción, antes de que el producto salga de la fábrica. La pieza se fabricó (el cambio se construyó en una rama), pero no se despacha directo al cliente: pasa primero por una estación donde alguien la inspecciona contra una lista, la aprueba o la devuelve. El pull request es esa estación de inspección para tus workflows. Y la regla de oro, la que separa un equipo serio de uno improvisado, es: nada se promueve a prod sin haber pasado por esa estación.

El ciclo, en su forma más simple, es este:

  1. Haces el cambio en una rama. No directo en la rama principal: en una rama aparte —recuerda las ramas del Módulo 2—, que es como un banco de trabajo separado donde armas la propuesta sin tocar lo que está en producción.
  2. Abres un pull request hacia la rama principal. GitHub te muestra el diff completo de lo que propones.
  3. Se revisa el diff. Alguien lo lee —idealmente otra persona; si trabajas solo, tú mismo con ojos frescos—, verifica que el cambio hace lo que dice y nada más, y deja comentarios o lo aprueba.
  4. Se integra (o se corrige). Si el diff está bien, se fusiona a la rama principal. Si algo no cuadra, se pide el ajuste y se revisa de nuevo.

Recién después de que el cambio está en la rama principal, revisado y aprobado, se promueve —con el import:workflow de la lección 2—. El pull request es la puerta; la promoción es el paso por la puerta. Sin la puerta, cualquier cambio entra a producción sin que nadie lo haya mirado, y eso es exactamente lo que un despliegue evita.

Trabajar solo también merece un pull request

Quizás pienses: "si soy yo solo, ¿para qué un pull request? Yo hice el cambio, yo sé qué hace". Es una objeción razonable y tiene una respuesta que vale oro.

El pull request, incluso solo, hace tres cosas que el commit directo no hace. Primero, te obliga a mirar tu propio cambio con ojos frescos, separado del momento en que lo escribiste —y es asombroso cuántos errores propios ves cuando el diff te los muestra ordenados, horas después de haberlos cometido—. Segundo, deja un registro: el PR queda como una nota de qué cambió, por qué, y cuándo se aprobó; es documentación que se escribe sola. Tercero, te entrena para el equipo: el día que trabajes con más gente, el ritual ya es tu hábito, no algo que tienes que aprender bajo presión.

Personalmente, yo, Mike, reviso mis propios cambios en un pull request incluso en proyectos de una sola persona, sobre todo cuando el cambio toca algo que va a producción. No por ceremonia: porque el "yo que escribe" y el "yo que revisa" son, en la práctica, dos personas distintas, y la segunda atrapa lo que la primera no vio.

Cómo leer el diff de un workflow con criterio

Tener el diff no es lo mismo que saber revisarlo. Revisar es hacerle preguntas al cambio. Estas son las que un dueño del sistema le hace a cada diff antes de aprobarlo:

  • ¿El cambio hace lo que dice el mensaje? Si el commit dice "subir el umbral a 5000", el diff debería mostrar eso y solo eso. Si además cambió un endpoint del CRM que nadie mencionó, hay una discrepancia entre lo dicho y lo hecho, y eso es una alarma.
  • ¿Cambió algo que no esperabas? Este es el corazón de la revisión. Un diff limpio (gracias a la normalización) hace que cualquier cambio inesperado salte a la vista. Si ves modificarse una URL, una credencial, un valor de configuración que el cambio no debería tocar, detente y entiende por qué antes de aprobar.
  • ¿Se coló un secreto? Aunque la disciplina del Módulo 3 hace difícil que un secreto llegue al JSON, la revisión es la segunda red. Busca en el diff cadenas con forma de token —sk-, Bearer , claves largas, password—. Un secreto en un diff es un alto absoluto.
  • ¿El cambio es reversible? ¿Sabrías volver atrás si este cambio rompe algo? Si el diff toca algo que no sabrías deshacer, esa es información sobre el riesgo del cambio, y quizás sobre la necesidad de un plan de rollback más cuidadoso (lección 5).

Fíjate en la pregunta que hace el trabajo pesado: "¿cambió algo que no esperaba?". Un buen diff de workflow es aburrido: muestra exactamente el cambio que anunciaste, ni una línea más. El día que el diff te sorprende es el día que la revisión te salvó. Y esa es la razón por la que un diff limpio importa tanto: en un diff ruidoso, la sorpresa se esconde entre el ruido; en un diff limpio, no tiene dónde esconderse.

Ejemplo trabajado: revisar un cambio de order-triage

Veamos una revisión real, con Cumbre. Alguien —una persona, o una IA, da igual para este ejemplo— propone un cambio en order-triage: "manejar el caso de pedidos sin cliente asociado". Abres el diff antes de aprobar la promoción.

Paso 1 — Mira el diff. Desde el repositorio, con el cambio ya en su rama:

git diff main feature/handle-missing-customer -- workflows/order-triage.json

Qué esperar: el diff te muestra qué cambió entre la rama principal (main) y la rama de la propuesta (feature/handle-missing-customer), solo para order-triage.json. Supón que ves algo así:

       {
         "parameters": {
-          "conditions": "={{ $json.customerId }}"
+          "conditions": "={{ $json.customerId ?? 'unknown' }}"
         },
         "name": "Check customer",
         "type": "n8n-nodes-base.if"
       },
+      {
+        "parameters": {
+          "url": "={{ $env.CRM_URL }}/customers/lookup",
+          "method": "GET"
+        },
+        "name": "Lookup missing customer",
+        "type": "n8n-nodes-base.httpRequest"
+      },

Paso 2 — Hazle las preguntas. Recorre el diff con la lista:

  • ¿Hace lo que dice? El mensaje era "manejar pedidos sin cliente asociado". El diff muestra dos cosas coherentes con eso: una condición que ahora tolera un customerId ausente (usando ?? 'unknown') y un nodo nuevo que busca al cliente faltante en el CRM. Coincide. Bien.
  • ¿Cambió algo inesperado? Recorre línea por línea. No hay ninguna modificación fuera de lo que el cambio anunció: no se tocó el umbral, ni el AI Agent, ni otra URL. El diff es aburrido en el buen sentido. Bien.
  • ¿Se coló un secreto? El nodo nuevo usa $env.CRM_URL —una referencia a una variable de entorno, no un valor hardcodeado— y no hay ningún token en claro. Bien.
  • ¿Es reversible? El cambio agrega un nodo y ajusta una condición; volver atrás sería quitar el nodo y restaurar la condición, que es justo lo que un git revert haría. Reversible. Bien.

Paso 3 — Decide. Las cuatro preguntas pasan. El diff es coherente con su intención, no esconde sorpresas, no filtra secretos y es reversible. Apruebas el pull request, se integra a main, y ahora —no antes— el cambio está listo para promoverse a staging y, tras su prueba, a prod.

Detente en el orden: revisaste antes de promover, no después. El diff fue tu inspección; el pull request, tu estación de control de calidad. Si en el paso 2 alguna pregunta hubiera fallado —un secreto en claro, una URL cambiada sin explicación—, habrías pedido corrección en vez de aprobar, y producción nunca se habría enterado del problema.

Los tres tipos de cambio que verás en un diff de workflow

No todos los cambios se ven igual en el diff, y reconocer los tipos te hace revisar más rápido. En el JSON de un workflow, un cambio cae casi siempre en una de tres categorías, y cada una merece un ojo distinto:

  • Cambio de parámetro. Se modifica un valor dentro de un nodo: un umbral de 1500 a 5000, una URL, un prompt del AI Agent. En el diff se ve como una línea con - y su reemplazo con +, dentro de un bloque parameters. Es el cambio más común y el más fácil de revisar: lees el valor viejo y el nuevo, y decides si tiene sentido. La pregunta clave aquí es de juicio: ¿5000 es un umbral razonable para Cumbre?
  • Cambio de estructura. Se agrega o se quita un nodo. En el diff se ve como un bloque entero con + (un objeto de nodo nuevo, con su name, type y parameters) o con - (un nodo que desaparece). Requiere más cuidado: un nodo nuevo puede introducir una llamada externa, una credencial, un efecto secundario. Pregúntate qué hace ese nodo, no solo que esté.
  • Cambio de conexión. Se cambia cómo los nodos se enlazan entre sí, sin tocar los nodos en sí. En el diff vive en la sección connections del JSON, y es el más traicionero, porque una conexión reordenada puede cambiar el flujo del workflow —qué corre antes que qué— sin que ningún nodo se vea distinto. Un diff que solo toca connections merece atención extra: el comportamiento pudo cambiar aunque los nodos sean los mismos.

Reconocer el tipo te orienta la revisión. Un cambio de parámetro es sobre todo juicio de negocio; uno de estructura, sobre qué capacidad nueva entra; uno de conexión, sobre si el flujo se alteró en silencio. Cuando abras un diff, la primera pregunta útil es "¿de qué tipo es este cambio?", porque la respuesta te dice dónde poner la atención.

Revisar lo que hizo una IA

Ahora el tema que hace especial a esta lección. n8n 2.0 permite que un asistente de IA —Claude, ChatGPT, Cursor— construya y edite workflows dentro de tu instancia, a través del servidor MCP que estudias a fondo en la lección 4. Eso cambia el paisaje de la revisión, y conviene entender exactamente qué cambia y qué no.

Lo que no cambia es lo esencial: un cambio hecho por una IA es un cambio, y pasa por la misma puerta que cualquier otro. La IA propone; Git registra el diff; un humano lo revisa y aprueba antes de que llegue a prod. La revisión de diff que acabas de practicar es idéntica venga el cambio de una persona o de una máquina. Esa es la buena noticia, y es el corazón de por qué esta guía te hizo aprender a versionar y revisar antes de tocar la IA: ya tienes la red que hace segura a la IA.

Lo que sí cambia son tres cosas que hacen la revisión de un cambio de IA más cuidadosa, no menos:

Primera: la IA genera más, y más rápido. Una persona hace un cambio pensado; una IA puede proponer cinco variantes en un minuto. El volumen sube, y con él la tentación de "aprobar en bloque" sin leer. Resiste esa tentación. Cada diff que llega a prod merece los mismos ojos, venga de quien venga. Si la IA propone mucho, revisas mucho; la solución no es revisar menos, es que la IA proponga contra un entorno donde su volumen no haga daño —dev, nunca prod— y que solo lo revisado se promueva.

Segunda: la IA a veces cambia más de lo que le pediste. Le pides "agrega un nodo para el caso de cliente faltante" y, de paso, "mejora" el nombre de otro nodo, reordena una conexión, o ajusta un valor que no venía al caso. Esos cambios colaterales son justo lo que la pregunta "¿cambió algo que no esperaba?" atrapa. Con una IA, esa pregunta pasa de importante a crítica: el diff limpio es tu defensa contra los cambios que la IA hizo "por iniciativa propia" sin que se lo pidieras.

Tercera: la IA no entiende las consecuencias de negocio. La IA puede producir un cambio técnicamente correcto que sea un desastre para Cumbre —bajar el umbral de revisión manual a 100 pesos, mandando todos los pedidos a revisión y colapsando al equipo, por ejemplo—. El diff se ve limpio, el JSON es válido, y aun así el cambio es malo. Aquí la IA no te puede ayudar: solo un humano que conoce el negocio de Cumbre sabe que 100 es un umbral absurdo. La revisión humana no es solo técnica; es de juicio, y el juicio sobre el negocio es exactamente lo que la IA no tiene.

El lazo seguro, entonces, es este —grábalo, porque es el principio que gobierna las lecciones 3 y 4—:

  la IA          Git           el humano        se promueve
 propone   →   registra   →    revisa el    →   a staging
 (en dev)      el cambio       diff y aprueba    y a prod

La IA es un colaborador poderoso y rápido, pero no es quien firma. Quien firma es el humano que leyó el diff. Esa firma —la aprobación del pull request— es lo que separa "dejé que una IA tocara mi sistema" de "usé una IA para construir más rápido, con la misma seguridad de siempre".

Por qué el diff es la mejor forma de revisar a una IA

Hay una razón profunda por la que el diff es la herramienta perfecta para revisar el trabajo de una IA, y vale la pena nombrarla.

Cuando le pides algo a una IA en lenguaje natural, la instrucción es difusa —"maneja mejor los pedidos raros"— y la respuesta puede ser cualquier cosa dentro de ese margen. Sin un diff, tendrías que confiar en que la IA entendió lo que quisiste, o releer el workflow entero para descubrir qué hizo. El diff elimina esa incertidumbre: te muestra, con precisión de línea, exactamente qué hizo la IA, sin interpretación. No te dice lo que la IA dice que hizo; te dice lo que hizo.

Esa diferencia —entre lo que la IA reporta y lo que efectivamente cambió— es donde viven los problemas. Una IA puede afirmar con total seguridad "agregué el manejo del cliente faltante" y, en el diff, haber además borrado una conexión importante. El texto de la IA no te lo diría; el diff sí. Por eso la regla no es "confía en lo que la IA te explica", sino "lee el diff de lo que la IA hizo". El diff es la fuente de verdad sobre el cambio; la explicación de la IA es, en el mejor de los casos, un resumen, y en el peor, una versión optimista.

Errores comunes

Revisar el JSON entero en vez del diff (práctico). Qué pasa: alguien, para "revisar bien", abre el order-triage.json completo e intenta leerlo de arriba abajo buscando el cambio. Se pierde entre cientos de líneas, se cansa, y termina aprobando sin haber encontrado de verdad qué se movió. Por qué pasa: parece que "revisar todo" es más riguroso que revisar el diff. Es al revés. Cómo detectarlo: si estás leyendo líneas del workflow que no cambiaron, estás gastando atención donde no hay nada que revisar. Cómo corregirlo: revisa el diff, no el archivo. El diff es precisamente lo que cambió, que es lo único que hay que decidir aprobar o no. Leer el archivo entero no es más riguroso; es menos efectivo, porque el cansancio te hace pasar por alto justo lo que importa.

Aprobar un pull request sin leer el diff porque "confío en quien lo hizo" (conceptual). Qué pasa: alguien aprueba el cambio de un compañero —o de una IA— sin abrir el diff, porque confía en la fuente. Un día esa confianza deja pasar un error que el diff habría mostrado en un vistazo. Por qué pasa: la confianza se siente como suficiente, y leer el diff se siente como desconfianza. No lo es: revisar no es desconfiar, es el proceso normal de un despliegue. Cómo detectarlo: si apruebas PRs sin abrir el diff, no estás revisando, estás sellando. Cómo corregirlo: lee siempre el diff, sin importar quién lo hizo. La revisión no es un juicio sobre la persona; es un control sobre el cambio. Los mejores ingenieros piden que revisen su código justamente porque saben que cualquiera comete errores, ellos incluidos.

Confiar en lo que la IA dice que hizo, en vez de leer lo que hizo (conceptual, específico de IA). Qué pasa: alguien le pide un cambio a la IA, la IA responde "listo, agregué X e Y", y la persona promueve basándose en esa descripción sin mirar el diff. Resulta que la IA además tocó Z, que rompió algo. Por qué pasa: la explicación de la IA es fluida y convincente, y da la sensación de que ya sabes qué cambió. Cómo detectarlo: si tu conocimiento de qué cambió viene del texto de la IA y no del diff, confiaste en el resumen. Cómo corregirlo: la IA propone, el diff dice la verdad. Lee el diff de cada cambio de IA como si la IA no te hubiera explicado nada; su explicación es una pista, no una garantía. La brecha entre lo que la IA dice y lo que hace es donde viven los problemas.

Dejar que el volumen de la IA baje el estándar de revisión (conceptual, específico de IA). Qué pasa: la IA propone diez cambios en una tarde, revisar diez diffs con cuidado es trabajo, y alguien empieza a "aprobar rápido" para no quedarse atrás del ritmo de la máquina. La calidad de la revisión se derrumba justo cuando más cambios están pasando. Por qué pasa: el humano intenta igualar la velocidad de la IA en la revisión, que es imposible y contraproducente. Cómo detectarlo: si apruebas más rápido cuando hay más cambios, el volumen te está ganando. Cómo corregirlo: el estándar de revisión no baja con el volumen; lo que baja es cuántos cambios dejas que la IA proponga de una vez. La IA construye contra dev a su ritmo; tú promueves solo lo que revisaste al tuyo. La velocidad de la máquina es para construir, no para saltarse el control.

Ejercicios

Ejercicio 1 — Revisa un diff con la lista. Te llega este diff propuesto para order-triage.json. Recórrelo con las cuatro preguntas de revisión y decide si lo aprobarías o pedirías cambios:

       {
         "parameters": {
-          "url": "={{ $env.CRM_URL }}/orders",
+          "url": "https://crm.cumbre.example/orders",
           "method": "POST",
-          "authentication": "genericCredentialType"
+          "authentication": "none"
         },
         "name": "Register order in CRM",
         "type": "n8n-nodes-base.httpRequest"
       }
Ver solución

Pedirías cambios; no lo apruebas. Recorriendo la lista:

  • ¿Hace lo que dice? No sabemos qué decía el mensaje, pero el diff hace dos cosas preocupantes que rara vez serían la intención declarada.
  • ¿Cambió algo inesperado? Sí, dos cosas graves. Primero, la URL pasó de $env.CRM_URL (una variable de entorno, que cambia por entorno) a una URL hardcodeada de producción (https://crm.cumbre.example/orders). Eso rompe la portabilidad entre entornos: ese workflow ahora apuntaría al CRM de producción incluso en dev y staging. Segundo, la autenticación pasó de genericCredentialType (usa una credencial) a none (sin autenticación). Eso o rompe la llamada, o —peor— la deja sin proteger.
  • ¿Se coló un secreto? No hay un token en claro, pero hardcodear la URL de producción es un primo cercano del problema: mete configuración de entorno donde no debe estar.
  • ¿Es reversible? Técnicamente sí, pero los dos cambios son señales de alarma que hay que entender antes de seguir.

Este diff es el ejemplo perfecto de por qué se revisa: se ve pequeño, pero esconde dos decisiones que romperían la separación de entornos y la autenticación. Un diff "aburrido" habría sido seguro; este es cualquier cosa menos aburrido.

Por qué funciona: el ejercicio te entrena a que ningún cambio pase solo por ser corto. Los dos problemas —la URL hardcodeada y la autenticación en none— son exactamente el tipo de cosa que una revisión atrapa y una promoción a ciegas deja pasar a producción.

Ejercicio 2 — Justifica el pull request para una sola persona. Un compañero que trabaja solo te dice: "El pull request es burocracia de equipos grandes; yo commiteo directo a main y ya, para qué me voy a revisar a mí mismo". Escríbele una respuesta de tres o cuatro frases que le dé al menos dos razones concretas para usar pull requests incluso trabajando solo.

Ver solución

Una respuesta posible:

"Entiendo el punto, pero el pull request te sirve incluso solo, por dos razones concretas. Primera: te obliga a mirar tu propio cambio como un diff, separado del momento en que lo escribiste, y vas a atrapar errores propios que no viste mientras los cometías —el 'yo que revisa' ve lo que el 'yo que escribe' pasó por alto—. Segunda: deja un registro de qué cambió y por qué, que es documentación que se escribe sola y que vas a agradecer dentro de seis meses cuando no recuerdes por qué tocaste ese nodo. Y hay una tercera: el día que trabajes con más gente, el hábito ya está puesto, no lo tienes que aprender bajo presión. No es burocracia; es el paso que convierte 'lo cambié' en 'lo cambié y lo revisé'."

Por qué funciona: la objeción es común y razonable, y la respuesta no la descarta con "hazlo porque sí", sino con beneficios concretos que aplican a una sola persona: revisión con ojos frescos, registro automático, y hábito para el futuro. Es la misma lógica de por qué versionar solo también vale la pena.

Ejercicio 3 — Revisa a la IA. Le pediste a una IA, vía MCP en tu instancia de dev, "agrega manejo de errores al nodo del CRM en order-triage". La IA responde: "Listo, agregué un nodo de reintento y un manejo de error en el nodo del CRM". Antes de promover, ¿qué haces exactamente, y por qué no te basta con la descripción de la IA?

Ver solución

Lo que haces: exportas el workflow que la IA modificó en dev, lo commiteas en una rama, y abres el diff contra la versión anterior. Después lo revisas con las cuatro preguntas: ¿el diff muestra el manejo de errores que pediste (y solo eso)?, ¿cambió algo que no esperabas?, ¿se coló algún secreto?, ¿es reversible? Solo si el diff pasa la revisión, apruebas y promueves a staging.

Por qué no basta la descripción de la IA: porque la descripción es lo que la IA dice que hizo, y el diff es lo que efectivamente hizo, y entre esas dos cosas es donde viven los problemas. La IA pudo haber agregado el manejo de errores y además haber tocado otra cosa —reordenado una conexión, cambiado un valor, borrado un nodo— sin mencionarlo. La descripción es un resumen optimista; el diff es la fuente de verdad. Además, la IA no sabe si el manejo de errores que agregó tiene sentido para el negocio de Cumbre; ese juicio lo pones tú al revisar.

Por qué funciona: este ejercicio instala el reflejo central de trabajar con IA en tu instancia: nunca promuevas basándote en lo que la IA te contó; promueve basándote en el diff que revisaste. La IA propone y construye rápido; el humano lee el diff y firma. Esa división de trabajo es lo que hace segura a la IA en un sistema de producción.

Resumen y siguiente paso

En esta lección instalaste el control de calidad que va antes de cada promoción: la revisión del cambio como diff. Entendiste que un diff es la lista exacta de qué cambió —líneas con + y -—, que la normalización del Módulo 3 es lo que lo hace legible, y que revisar es hacerle cuatro preguntas al cambio: ¿hace lo que dice?, ¿cambió algo inesperado?, ¿se coló un secreto?, ¿es reversible? Conociste el pull request como la estación de control de calidad obligatoria —la puerta por la que un cambio pasa antes de integrarse y promoverse—, y por qué vale la pena incluso trabajando solo: revisión con ojos frescos, registro automático y hábito para el equipo. Y enfrentaste el tema nuevo del módulo: revisar workflows que una IA creó o modificó. Lo esencial no cambia —la IA propone, Git registra, el humano aprueba el diff antes de prod—, pero la revisión se vuelve más cuidadosa por tres razones: la IA genera más y más rápido, a veces cambia más de lo que le pediste, y no entiende las consecuencias de negocio. El diff es la mejor forma de revisarla porque muestra lo que la IA hizo, no lo que dice que hizo.

Antes de avanzar deberías poder: leer un diff de workflow y aplicarle las cuatro preguntas; explicar qué es un pull request y por qué es obligatorio incluso solo; y describir el lazo seguro para cambios de IA —proponer en dev, registrar en Git, aprobar el diff, promover—.

La lección 4 cierra el círculo de la IA. Hasta aquí supusiste que "una IA modificó el workflow"; ahora vas a ver cómo lo hace: el servidor MCP a nivel de instancia de n8n, que deja a un asistente de IA construir y editar workflows dentro de tu n8n. Vas a aprender a apuntarlo a un entorno no-prod —dev, nunca producción—, a entender el lazo seguro completo, sus límites y permisos, y por qué los entornos aislados que montaste en el Módulo 4 son exactamente la red de seguridad que hace posible dejar que una máquina toque tus workflows sin miedo.

Recursos

← Anterior2. Promover workflows entre entornosSiguiente →4. MCP para construir workflows contra entornos no-prod