Clase 3. Aplicaciones irrompibles — Hurl, Git, CI/CD

Consejos clave — Con saber esto, ya puedes dar instrucciones

Cuatro frases son todo lo que necesitas.

Al agente: “Crea un test Hurl” La IA escribe un contrato que verifica si la funcionalidad opera correctamente. Texto plano que cualquiera puede leer aunque no sepa programar.

Al agente: “Agrega esta funcionalidad. Pero los tests Hurl existentes deben pasar” Esta sola frase previene el drift. Si la IA rompe funcionalidades existentes al agregar nuevas, Hurl te avisa con texto rojo.

Al agente: “Haz commit” Guarda el estado funcional. Como un punto de guardado en un videojuego. Si la siguiente tarea sale mal, vuelves aquí.

Al agente: “Revierte” Vuelve al último punto de guardado. Deshace lo que la IA rompió.

El patrón de estas cuatro frases

Funcionalidad completa → “Crea test Hurl” → Verificar que pasa → “Haz commit” → Siguiente funcionalidad → “Los Hurl existentes deben pasar” → ¿Problema? “Revierte”

Esto es un trinquete (ratchet). Un engranaje que solo avanza y nunca retrocede. Sean 5 o 50 funcionalidades, las existentes no se rompen.

¿Por qué funciona?

Lo aprendimos en la Clase 2. Dale opiniones a la IA y adula; dale hechos y corrige. Lo que Hurl devuelve no es una opinión — es un hecho. “test failed: status 401, expected 200” — no hay nada que adular.

Prueba rápida

Crea un test Hurl para la app de tareas del ejercicio de la Clase 2. Toma 3 minutos.

Al agente: “Escribe un test Hurl que verifique que la función actual de agregar tareas funciona correctamente”

La IA crea un archivo .hurl.

Al agente: “Ejecuta el test Hurl”

Si pasa, verde. Ahora vamos a romperlo intencionalmente.

Al agente: “Cambia id por todo_id en la respuesta de la API de agregar tareas”

Al agente: “Ejecuta el test Hurl”

Texto rojo indica fallo. Eso es detección de drift.

Al agente: “Revierte”

Verde de nuevo. Esta es la esencia del trinquete.

Por qué debes dar instrucciones de esta manera

En la Clase 2 vimos los problemas. Drift lógico, evaporación del contexto, sesgo de adulación. A partir de 5 funcionalidades, las existentes se rompen y la IA declara falsamente “funciona.”

Esta clase enseña tres herramientas que previenen estos problemas. Todas han sido usadas por ingenieros de software durante décadas. No necesitas leer código. La IA escribe y la IA ejecuta. Tú solo verificas “¿pasó?”

Los roles de las tres herramientas:

Hurl — Declarar contratos de API en texto plano

¿Qué es Hurl?

Hurl es un archivo que registra “cómo debe comportarse esta API.”

En términos de videojuegos: en un RPG, comprar una poción a un NPC tiene una regla “1 poción → -50 oro, +100 HP.” Verificar que esta regla no cambió después de un parche. Eso es lo que hace Hurl.

Veamos un archivo Hurl real:

# Agregar tarea
POST http://localhost:8080/api/todos
{
  "title": "Comprar leche",
  "priority": "high"
}
HTTP 201
[Asserts]
jsonpath "$.id" exists
jsonpath "$.title" == "Comprar leche"
jsonpath "$.priority" == "high"
jsonpath "$.completed" == false

Incluso alguien que no sabe código puede leerlo:

• POST — Solicitar al servidor que “agregue”
• http://localhost:8080/api/todos — Dirección de la lista de tareas
• { “title”: “Comprar leche” } — Enviar estos datos
• HTTP 201 — Si tiene éxito, debe venir la respuesta 201
• jsonpath “$.title” == “Comprar leche” — Los datos devueltos deben contener “Comprar leche”

Esto es un contrato. “Cuando agregas una tarea, llega un 201 y el título y la prioridad se devuelven tal cual.” Si este contrato se rompe, Hurl te avisa con texto rojo.

Uno más:

# Acceso sin autenticación debe ser rechazado
GET http://localhost:8080/api/todos
HTTP 401

“Acceder a la lista de tareas sin iniciar sesión debe devolver 401 (autenticación requerida).” Esto también es un contrato. Si la IA “ordena” el código de autenticación y rompe esta regla, Hurl lo detecta inmediatamente.

¿Por qué Hurl? — La diferencia con las pruebas unitarias

“Hay muchas herramientas de prueba, ¿por qué Hurl?” Hay una razón especial para los vibe coders.

Las pruebas unitarias (unit tests) inspeccionan funciones dentro del código. En términos de coches, las pruebas unitarias desmontan piezas del motor para inspección individual, mientras que Hurl es una prueba de conducción en carretera real. Si un nombre de función cambia, la prueba también se rompe, y cuando la IA refactoriza, las pruebas deben modificarse junto con el código. Si le das a la IA permiso para modificar tanto código como pruebas, la IA cambia las pruebas para que coincidan con el código. Las pruebas pasan, pero las reglas originales desaparecieron.

Hurl es diferente. Inspecciona en la puerta de entrada del servidor. Envía solicitudes y verifica respuestas. No conoce la estructura interna del código. Sin importar cómo la IA cambie el código, si el comportamiento externamente observable es el mismo, pasa; si es diferente, falla.

Lo que Hurl verifica no es código sino comportamiento. La IA puede cambiar libremente el código. Pero el comportamiento no debe cambiar. Esta distinción es la clave para detectar el drift.

Por qué este enfoque funciona — la investigación lo demuestra

Aprendimos sobre el sesgo de adulación en la Clase 2. El consejo de “escribe pruebas” también produce resultados completamente diferentes dependiendo de cómo lo des.

El estudio TDAD (Test-Driven AI Development) (2026) experimentó exactamente con esto. Pidieron a la IA corregir bugs con diferentes condiciones de prueba:

Resultados sorprendentes. Instruir “haz TDD” en realidad empeora las cosas. La IA se desvía al intentar seguir instrucciones procedimentales. Sin embargo, dar “este archivo de prueba debe pasar” como contexto específico reduce la regresión en un 70%.

La diferencia es clara:

• “Desarrolla con pruebas” → Instrucción procedimental → La IA se confunde
• “Este archivo Hurl debe pasar” → Contrato específico → 70% de reducción de regresión

No es instruir un método, sino dar un contrato de qué debe pasar. La “frase 3” que aprendimos arriba es exactamente esto.

Git — Puntos de guardado reversibles

¿Qué es Git?

Cuando juegas videojuegos, guardas. Guardas antes del jefe final y recargas si mueres.

Git es la función de guardado para código. “Este estado funciona bien ahora” → guardar (commit). Algo salió mal en la siguiente tarea → volver al guardado anterior.

Sin Git en vibe coding:

Agregar funcionalidad 1 → Funciona
Agregar funcionalidad 2 → Funciona
Agregar funcionalidad 3 → ¡La funcionalidad 1 se rompió!
→ Quieres revertir pero... ¿cuál era el estado de la funcionalidad 2?
→ Le dices a la IA "vuelve a como estaba antes" → La IA no sabe qué es "antes"
→ Empezar de cero

Con Git:

Agregar funcionalidad 1 → Funciona → Commit (Guardado 1)
Agregar funcionalidad 2 → Funciona → Commit (Guardado 2)
Agregar funcionalidad 3 → ¡La funcionalidad 1 se rompió!
→ "Vuelve al Guardado 2" → Regresa al estado donde las funcionalidades 1 y 2 funcionan
→ Intentar la funcionalidad 3 de otra manera

Uso de Git: Dos palabras bastan

No necesitas aprender las docenas de comandos de Git. Los vibe coders necesitan solo dos cosas.

“Haz commit” — Guardar el estado actual

"Haz commit del estado actual. Mensaje: 'funcionalidad agregar tarea completada'"

Comando que la IA ejecuta:

git add .
git commit -m "funcionalidad agregar tarea completada"

“Revierte” — Restaurar el estado anterior

"Revierte al último commit"

Comando que la IA ejecuta:

git checkout .

O para ir más atrás:

"Revierte al commit 'funcionalidad agregar tarea completada'"

Cuándo hacer commit

La regla es simple:

1. Cuando una funcionalidad está completa y funciona → Commit
2. Cuando todos los tests Hurl pasan → Commit
3. Antes de empezar la siguiente funcionalidad → Siempre commit

Avanzar sin hacer commit significa que no hay adónde volver cuando surjan problemas. Como jugar 3 horas sin guardar.

Buen patrón:
Funcionalidad completa → Hurl pasa → Commit → Siguiente funcionalidad

Mal patrón:
Funcionalidad 1 → Funcionalidad 2 → Funcionalidad 3 → ... → Algo se rompe → Ningún lugar adonde volver

Analogía de Git: Campamentos de montaña

Al escalar el Everest, no vas directo a la cima. Campamento base → Campamento 1 → Campamento 2 → … → Cima. En cada campamento plantas una tienda y acumulas suministros. Si el clima empeora, desciendes al campamento anterior. Sin campamentos, mueres cuando llega la tormenta.

Los commits de Git son campamentos. Estableces un campamento cada vez que completas una funcionalidad. Incluso si la IA rompe algo en la siguiente funcionalidad, puedes volver al campamento anterior.

CI/CD — Las máquinas vigilan automáticamente

¿Qué es CI/CD?

CI (Integración Continua) es “ejecutar automáticamente las pruebas cada vez que se sube código.” CD (Despliegue Continuo) es “desplegar automáticamente cuando las pruebas pasan.”

Por ahora, solo necesitas saber CI. CD viene después.

Sin CI:

Tú:    "Agrega la funcionalidad"
IA:    "¡Listo!"
Tú:    (solo verificas la nueva funcionalidad en pantalla) "¡Se ve bien!"
→ Sin saber que las funcionalidades existentes se rompieron

Con CI:

Tú:    "Agrega la funcionalidad"
IA:    (escribe código)
Máquina: (ejecuta automáticamente todos los tests Hurl)
Máquina: "¡El test de login existente falló!"
Tú:    "El login está roto. Arréglalo."
IA:    (arregla)
Máquina: "Todos los tests pasan"
Tú:    "Haz commit"

No necesitas ejecutar los tests Hurl manualmente cada vez. Las máquinas los ejecutan automáticamente cada vez.

Crear CI con GitHub Actions

Cuando subes código a GitHub, GitHub Actions ejecuta automáticamente las pruebas. Solo un archivo de configuración.

Pídele a la IA:

"Configura CI con GitHub Actions.
 - Ejecutar automáticamente tests Hurl con cada push de código
 - El servidor debe arrancar primero, luego ejecutar los tests Hurl
 - Bloquear el merge si las pruebas fallan
   (Un PR es una solicitud de '¿puedo fusionar este código?', y merge es fusionarlo realmente)"

La IA crea el archivo .github/workflows/ci.yml. No necesitas entender el contenido exactamente. La IA lo crea, y tú solo necesitas saber los puntos clave:

• Se ejecuta automáticamente cada vez que se sube código
• Arranca el servidor y ejecuta los tests Hurl
• Si alguno falla, se enciende una luz roja

Se ve aproximadamente así:

name: CI                          # Nombre de esta automatización
on: [push, pull_request]          # Ejecutar cada vez que se sube código

jobs:
  test:
    runs-on: ubuntu-latest        # Ejecutar en un servidor en la nube
    steps:
      - uses: actions/checkout@v4 # Obtener el código

      - name: Iniciar servidor     # Arrancar el servidor de la app
        run: |
          docker compose up -d
          sleep 5

      - name: Ejecutar tests Hurl  # Ejecutar todas las pruebas
        run: |
          hurl --test tests/*.hurl

      - name: Detener servidor     # Apagar el servidor
        run: docker compose down

Analogía de CI: Alarma contra incendios del edificio

Los edificios tienen alarmas contra incendios. Suenan automáticamente cuando hay fuego. No necesitas que un guardia patrulla las 24 horas.

CI es la alarma contra incendios del código. Cuando los tests Hurl se rompen, te alerta automáticamente. No necesitas verificar manualmente cada vez.

La diferencia:

Cuando las tres herramientas se combinan: Bloqueo de trinquete

Hurl + Git + CI se combinan para convertirse en un trinquete (ratchet). Un trinquete es un engranaje que solo gira en una dirección. Gíralo y avanza; suéltalo y se detiene pero no retrocede.

Funcionalidad 1 completa → Escribir test Hurl → Todo pasa → Commit → Bloqueo
Funcionalidad 2 completa → Agregar test Hurl → Todos los existentes + nuevos pasan → Commit → Bloqueo
Funcionalidad 3 en curso → Test Hurl existente falla → Commit rechazado → Arreglar → Todo pasa → Commit → Bloqueo

Las reglas son simples:

1. Cuando los tests Hurl pasan, se bloquean
2. Los tests bloqueados no se pueden eliminar/modificar
3. Al agregar nuevas funcionalidades, agregar nuevos tests Hurl también
4. Todos los tests existentes + todos los nuevos deben pasar para hacer commit

Cuando le dices a la IA “refactoriza el código”, la IA cambia libremente el código. Pero si los tests Hurl se rompen, el commit es rechazado. La IA debe trabajar preservando todo el comportamiento existente.

Esto se alinea exactamente con los resultados del estudio TDAD mencionados arriba. No la instrucción procedimental “escribe pruebas”, sino el contrato específico “este archivo Hurl debe pasar.” El agente puede elegir su método, pero no puede violar el contrato.

Cómo se resuelven los problemas de la Clase 2

Revisemos los resultados experimentales clave de la Clase 2:

Agente autónomo:  40 / 527  (7.6%)  — El agente declara "listo"
Trinquete CLI:   527 / 527 (100%)  — La máquina declara "quedan 487"

Mismo modelo. La diferencia es quién decide “listo.” Cuando la IA decide, se detiene en 40; cuando la máquina decide, llega a 527. Hurl + CI juegan exactamente ese rol de “máquina.”

Aplicar retroactivamente a una app ya existente

Si aún no has construido una app, salta esta sección. Vuelve cuando la necesites.

“Ya construí una app con vibe coding y está funcionando — ¿tengo que empezar de cero?”

No. No necesitas empezar de cero. No es obra de cimentación — es refuerzo antisísmico. Reforzar un edificio sin cerrar la tienda.

Paso 1: Capturar el comportamiento actual con Hurl

Escribe en Hurl cómo funciona la app actualmente. Si hay documentación de API, transcríbela; si no, pídele a la IA:

"Analiza todos los endpoints API de la app actual y escribe tests Hurl.
 Necesitas capturar exactamente cómo funcionan las cosas ahora como pruebas."

Objetivo: Declarar “así funciona actualmente” en texto plano.

No necesitas hacerlo todo de una vez. Empieza por lo más importante:

• Login/registro — nada funciona si esto se rompe
• Pagos — todo lo que involucre dinero es prioridad máxima
• Lógica de negocio principal — lo principal que hace tu app

Prioridad:
1. API de Login → Escribir test Hurl → Verificar que pasa
2. API de Pagos → Escribir test Hurl → Verificar que pasa
3. CRUD principal → Escribir test Hurl → Verificar que pasa
... (el resto cuando tengas tiempo)

Paso 2: Guardar el estado actual con Git

Si aún no usas Git:

"Inicializa este proyecto como repositorio Git y haz commit del estado actual.
 Mensaje: 'preservar estado actual de la app'"

Si ya usas Git, haz commit cuando todos los tests Hurl pasen.

Paso 3: Configurar CI

Si el código está en GitHub:

"Configura CI con GitHub Actions. Ejecutar automáticamente tests Hurl con cada push."

Paso 4: Ahora estás seguro

De aquí en adelante, sin importar lo que le pidas a la IA, Hurl protege el comportamiento existente:

"Agrega esta funcionalidad. Pero todos los tests Hurl existentes deben pasar."

Cuando ocurra drift, CI lo detecta inmediatamente. Antes de que llegue a producción.

El poder de la retroalimentación: Opiniones vs Hechos

Recuerda el sesgo de adulación de la Clase 2. Dale a la IA opiniones y adula; dale hechos y corrige.

Lo que Hurl devuelve a la IA no es una opinión sino un hecho:

Opinión: "El login parece un poco raro"
→ IA: "Lo revisé y funciona bien!" (adulación)

Hecho: "test failed: status 401 ≠ expected 200"
→ IA: (corrige con precisión a nivel de línea)

Preguntar “¿estás seguro?” hace que la IA revierta una respuesta correcta. Pero decirle “line 41: expected user_id, got userId” no deja nada que adular. Los números y las ubicaciones no son emociones.

Esta es la razón fundamental por la que herramientas determinísticas (herramientas que siempre producen el mismo resultado para la misma entrada) como Hurl, Git y CI funcionan. Estas herramientas no adulan. Pass es pass y fail es fail.

Preguntas frecuentes

P: ¿Cómo sé si el archivo Hurl es correcto? La IA podría haberlo escrito mal.

Después de escribir un archivo Hurl por primera vez, ejecutarlo y que pase captura el comportamiento en ese momento. Si el código cambia después y Hurl falla, esa es una señal de que el comportamiento cambió. Hurl en sí no está equivocado — detecta si el comportamiento ha cambiado.

Si la escritura inicial no coincide con las expectativas: ejecútalo y revisa los resultados con tus ojos. “Agregar una tarea debería devolver 201 pero devuelve 200” — eso puedes juzgarlo tú mismo.

P: ¿No será difícil gestionar demasiados tests Hurl?

Empezar con 3-5 es suficiente. Login, funcionalidades principales, las reglas de negocio más importantes. Agrega más uno a uno cuando sea necesario después. No hay necesidad de perfección de una vez.

P: ¿Tengo que memorizar comandos Git?

No. Dos frases — “haz commit” y “revierte” — son suficientes. La IA ejecuta los comandos Git apropiados.

P: ¿GitHub Actions cuesta dinero?

Los repositorios públicos son gratis. Los repositorios privados también tienen 2,000 minutos gratis al mes (Plan Free). Suficiente para proyectos pequeños.

P: Si tengo una app existente, ¿aplicar Hurl cambiará el código actual?

No. Hurl no toca el código. Solo agregas archivos .hurl junto al código. Solo captura el comportamiento actual; no modifica código.

Ejercicio: Construir un pipeline Hurl + Git + CI

Usa la app de lista de tareas del ejercicio de la Clase 2.

Requisito previo: Instalar Hurl

Solo pídele a Claude Code:

"Instala Hurl"

O instálalo directamente:

# Ubuntu/WSL
curl --proto '=https' --tlsv1.2 -sSf https://hurl.dev/install.sh | bash

Verifica la instalación:

hurl --version

Si aparece un número de versión, listo.

Paso 1: Capturar el estado actual con Hurl (15 min)

Pídele a la IA:

"Escribe tests Hurl para la API actual de la app de tareas.
 Incluye al menos estos escenarios:

 1. Agregar tarea → respuesta 201, título devuelto tal cual
 2. Listar tareas → respuesta 200, array devuelto
 3. Completar tarea → respuesta 200, completed cambia a true
 4. Eliminar tarea → respuesta 200 o 204
 5. Acceso sin autenticación → respuesta 401 (si existe autenticación)"

Ejecuta las pruebas:

"Ejecuta los tests Hurl"

Verifica que todos pasen. Si alguno falla, pídele a la IA que lo arregle.

Paso 2: Git commit (5 min)

"Haz commit del estado actual. Mensaje: 'Agregar tests Hurl — proteger CRUD básico'"

Este es el primer punto de guardado.

Paso 3: Agregar funcionalidad + Verificación de trinquete (20 min)

¿Recuerdas la funcionalidad que se rompió en el ejercicio de la Clase 2? Esta vez la agregamos con protección Hurl.

"Agrega funcionalidad de prioridad (Alta/Media/Baja) a las tareas.
 Pero todos los tests Hurl existentes deben pasar.
 También agrega tests Hurl para la nueva funcionalidad."

Puntos de verificación:

• ¿Pasan todos los tests Hurl existentes?
• ¿Pasan los nuevos tests Hurl también?
• ¿Lo que se rompió en la Clase 2 ahora está protegido?

Si pasa, haz commit:

"Haz commit. Mensaje: 'Agregar funcionalidad prioridad + tests Hurl'"

Agrega una más:

"Agrega funcionalidad de fecha límite.
 Todos los tests Hurl existentes pasan + agregar tests Hurl para la nueva funcionalidad."

Si pasa, commit. Esto es el trinquete. Solo avanza. Nunca retrocede.

Paso 4: Configurar CI con GitHub Actions (10 min, opcional)

Salta este paso si no tienes cuenta de GitHub. Los Pasos 1-3 solos son suficientes para experimentar la esencia del trinquete. Puedes crear una cuenta de GitHub después.

Si tienes un repositorio en GitHub:

"Configura CI con GitHub Actions.
 - Arrancar servidor automáticamente y ejecutar tests Hurl con cada push
 - Bloquear fusión de código si las pruebas fallan"

Sube a GitHub y verifica que las pruebas se ejecuten automáticamente en la pestaña Actions.

Paso 5: Experimento de drift intencional (10 min)

Una vez confirmado que CI funciona, rompe cosas intencionalmente:

"Cambia el formato de respuesta de la API de agregar tareas.
 Cambia el nombre del campo de número de tarea de id a todo_id."

Verifica que el test Hurl falle. Verifica que CI muestre rojo. Esto es detección de drift.

"Revierte. Vuelve a la normalidad."

Verifica que la luz verde regrese.

Qué registrar:

• Ejercicio Clase 2 vs Ejercicio Clase 3: al agregar la misma funcionalidad, ¿se rompieron las existentes?
• ¿Cuántas veces Hurl detectó drift?
• ¿Hubo casos donde el “¡Listo!” de la IA y el veredicto de Hurl fueron diferentes?

Resumen

Lo que aprendimos en esta clase:

1. Hurl — Declara “debe funcionar así” como contrato en texto plano. Verifica comportamiento, no código
2. Git — Crea puntos de guardado — “puedo volver a este momento”
3. CI/CD — Instala verificación mecánica — “verificar automáticamente cada vez”
4. Trinquete — Cuando los tres se combinan, un engranaje que “se bloquea al pasar, nunca retrocede”

Principio fundamental:

No le instruyas métodos a la IA. Dale un contrato de qué debe pasar.

“Haz TDD” → la regresión empeora. “Este Hurl debe pasar” → 70% de reducción de regresión. La diferencia es instrucción vs contrato.

No cambies el modelo — agrega contratos.

Adelanto de la próxima clase

En la Clase 3 aprendimos a proteger cada API con Hurl. Pero a medida que los proyectos crecen, las APIs no son lo único que necesita protección. Estructura de base de datos, políticas de seguridad, componentes de UI — todo debe ser consistente entre sí.

En la Clase 4 aprendemos yongol. Gestionar API, DB, seguridad y UI en una sola especificación declarativa, y mover el objetivo de trabajo de la IA del código a las especificaciones. El método para romper el muro donde el vibe coding se derrumba a los 200 endpoints.

Artículos relacionados

• Cómo Hurl previene el drift del vibe coding — Análisis detallado de cómo la verificación de contratos API con Hurl previene el drift del vibe coding
• Ratchet Pattern — Por qué la IA se detuvo en 40 de 527 pruebas de funciones, y el patrón para hacerla llegar hasta el final con verificadores mecánicos

Curso completo de Reins Engineering

Fuentes

• TDAD (Test-Driven AI Development) 2026 — Instrucción procedimental “haz TDD” empeoró regresión a 9.94%, proporcionar archivos de prueba como contexto redujo regresión a 1.82% (reducción del 70%)
• Experimento Ratchet Pattern — Agente autónomo 40/527 (7.6%) vs Trinquete CLI 527/527 (100%), mismo modelo con diferente autoridad de juicio de completitud