Clase 10. La ley de los datos — Agent Operable Data

Consejos clave — Con saber esto, ya puedes dar instrucciones

Estructuramos el código (Clase 8) y el sistema (Clase 9). Lo que queda son los datos. Los datos son lo más peligroso. Cuando el código está mal, los tests lo detectan. Cuando el sistema está mal, /health lo detecta. Cuando los datos están mal, nadie lo sabe. Se descubre 3 meses después en un informe trimestral.

Al agente: “Crea el esquema con columnas explícitas y restricciones en lugar de JSONB. amount debe ser mayor que 0, status solo acepta valores definidos.”

Meter cualquier cosa en JSONB significa 100 formatos diferentes mezclados después de 6 meses. Las columnas explícitas y las restricciones son la ley de los datos. La DB rechaza inmediatamente las violaciones de restricciones.

Al agente: “Importa este Excel a la DB. Las restricciones del DDL deben respetarse. Reporta en un archivo aparte las filas que violen restricciones.”

El agente ejecuta la conversión y las restricciones de la DB validan. Las filas rechazadas se reportan con las razones. Tú solo verificas los datos rechazados.

Al agente: “Modifica el DDL y que pase yongol validate. Genera archivos de migración, revierte en caso de fallo.”

El trinquete funciona incluso cuando los esquemas cambian. Pasa y avanza al siguiente paso, falla y revierte.

Lo único que tú haces como alguien que no conoce DB es decidir “qué almacenar.” “Los teléfonos deben empezar con 010”, “los emails deben ser únicos” — di estas decisiones en lenguaje natural y el agente las traduce a DDL.

Prueba rápida

Puedes probar sin DB. En Claude Code:

“Crea datos CSV: 10 clientes con nombre, email, teléfono, fecha de registro. Mezcla problemas intencionalmente: 2 con formato de email incorrecto, 1 con teléfono vacío, 1 con fecha de registro futura.”

Una vez generado el CSV:

“Encuentra las filas problemáticas en este CSV.”

Mira cuántas encuentra la IA. Lo más probable es que no las encuentre todas — algunas filas pasan con “se ven bien.”

Ahora:

“Primero define un esquema para este CSV. El email debe contener @, el teléfono es NOT NULL, la fecha de registro es anterior a hoy. Valida de nuevo con ese esquema.”

Con un esquema declarado primero, la IA detecta mecánicamente todo. Pide opiniones y se le escapan; dale reglas y los atrapa — el principio de la Clase 7 se aplica idénticamente a los datos.

Por qué debes dar instrucciones de esta manera

Introducción: Los datos se corrompen antes que el código

Estructuramos el código (Clase 8). Estructuramos el sistema (Clase 9). Lo que queda son los datos.

Pero los datos son fundamentalmente diferentes del código o los sistemas.

Cuando el código está mal, los tests lo detectan. Ejecuta go test y en 1 segundo dice “aquí se rompió.” Cuando el sistema está mal, el monitoreo lo detecta. /health devuelve 500 y suena una alarma inmediatamente.

Cuando los datos están mal, nadie lo sabe.

El teléfono de un cliente debería empezar con 010 pero alguien ingresó uno que empieza con 02. El monto de un pedido es negativo. El estado de envío es “en tránsito” pero la fecha de envío es null. Estos errores no los detectan los tests. Ni el monitoreo. Se descubren 3 meses después en un informe trimestral: “¿por qué los ingresos son negativos?”

El drift del código es visible. El drift de los datos es invisible.

Por eso los datos son más peligrosos que el código.

Tres tipos de corrupción de datos

1. Sin esquema — Transacciones sin contrato

Si solo le dices al agente “crea una tabla de pedidos”:

-- Si lo haces así
CREATE TABLE orders (
    id SERIAL,
    data JSONB    -- cualquier cosa entra aquí
);

Estas tres líneas son la causa raíz de 100 formatos diferentes mezclados después de 6 meses.

2. Migración fallida — Colisión entre pasado y presente

Le dices al agente “agrega campo email a la tabla de usuarios.” El agente modifica el DDL y ejecuta la migración. Los nuevos usuarios tienen email. Los 100,000 usuarios existentes tienen email como null. El código asume que email siempre existe. Los usuarios existentes inician sesión y obtienen errores 500.

3. Violación de reglas de negocio — Datos que no deberían permitirse

“La tasa de descuento debe estar entre 0-50%.” Si esta regla solo existe en el código, el agente puede eliminarla durante la refactorización. Sin restricción CHECK (discount >= 0 AND discount <= 50) en la DB, un descuento del 200% entra y nadie lo sabe.

4 condiciones para Agent Operable Data

Condición 1. El esquema está declarado — DDL es el contrato de los datos

CREATE TABLE orders (
    id          BIGINT       GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    customer_id BIGINT       NOT NULL REFERENCES customers(id),
    amount      DECIMAL(12,2) NOT NULL CHECK (amount > 0),
    status      TEXT         NOT NULL DEFAULT 'pending'
                             CHECK (status IN ('pending', 'confirmed', 'shipped', 'delivered', 'cancelled')),
    created_at  TIMESTAMPTZ  NOT NULL DEFAULT now(),
    shipped_at  TIMESTAMPTZ,
    CONSTRAINT  shipped_requires_date 
                CHECK (status != 'shipped' OR shipped_at IS NOT NULL)
);

Leamos este DDL. Incluso alguien que no es agente puede leerlo.

• amount debe ser mayor que 0 — pedidos negativos imposibles
• status debe ser uno de 5 — valores arbitrarios como “processing” son rechazados
• shipped_at debe existir cuando status es ‘shipped’ — previene “en tránsito pero sin fecha de envío”
• customer_id debe existir en la tabla customers — previene clientes fantasma

DDL es el contrato de los datos. Tipos, restricciones y relaciones son explícitas.

Condición 2. Las transformaciones son verificables

Los datos se transforman. De CSV a DB. De una tabla a otra. De datos crudos a informes.

Las reglas de transformación deben ser declarativas y los resultados mecánicamente verificables.

# Transformación no verificable
Al agente: "Mete este Excel en la DB"
→ El agente mapea columnas por su cuenta
→ 3,000 de 100,000 filas mal mapeadas
→ Nadie lo sabe

# Transformación verificable
Al agente: "Mete este Excel en la DB.
Reglas de mapeo según transform.yaml.
Después de importar, compara el conteo de filas,
verifica que la suma de amount coincida con el original."

Condición 3. Se rastrean el origen y la marca de tiempo

“¿Cuándo, dónde y por qué se creó este dato?”

Las máquinas deben poder responder esta pregunta.

CREATE TABLE orders (
    ...
    source      TEXT         NOT NULL,   -- 'web', 'api', 'import', 'migration'
    created_at  TIMESTAMPTZ  NOT NULL DEFAULT now(),
    created_by  BIGINT       REFERENCES members(id),
    updated_at  TIMESTAMPTZ,
    updated_by  BIGINT       REFERENCES members(id)
);

Así como whyso rastrea el “por qué” del código, el “por qué” de los datos también debe rastrearse. El código tiene whyso. Los datos tienen columnas de origen/marca de tiempo para ese rol.

Condición 4. El trinquete también se aplica a los cambios de datos

El Ratchet Pattern de la Clase 6 no solo se aplica al código. Se aplica a los datos también.

Trinquete de migración:

Solicitud de cambio de esquema
→ Modificación del DDL
→ yongol validate (pasa validación cruzada)
→ Archivo de migración auto-generado (up + down)
→ Aplicar a DB de staging
→ Verificar integridad de datos existentes
→ Pasa → Aplicar a producción (puerta de aprobación)
→ Falla → Revertir con archivo down

yongol ya implementa esto. yongol generate detecta cambios en DDL y auto-genera archivos de migración. Los archivos up y down vienen en pares. No hay migraciones irreversibles.

El esquema es la ley que yo establezco

Aquí aparece la filosofía que atraviesa todo el curso.

En la Clase 5 aprendimos “las restricciones son contratos.” Las tres condiciones del estado de derecho — verificable, la violación está definida, se puede hacer cumplir — se aplican idénticamente al código.

En los datos, este principio se manifiesta más directamente.

Las bases de datos tienen esquemas.

Los esquemas definen qué son datos válidos y qué no. NOT NULL, FOREIGN KEY, CHECK — los datos deben pasar estas restricciones para ser almacenados. Sin importar quién inserte los datos. Sea humano, programa o IA — si satisface el esquema, entra; si no, se rechaza. Un patrón que funciona desde 1970.

El esquema es ley. Ley que yo establezco.

Esto conecta con la visión del autor:

La ley no es justicia (正義) sino definición (定義).

La ley no garantiza justicia. Los esquemas tampoco garantizan la “verdad” de los datos. Pero la ley garantiza definición. Los esquemas garantizan validez.

Esta garantía mínima — conocible de antemano, mecánicamente verificable, las violaciones son rechazadas — es lo que la humanidad ganó con sangre durante miles de años, y lo que las bases de datos han demostrado durante 50 años.

Datos sin esquema son una sociedad sin ley. Cualquiera puede meter cualquier dato. Los datos incorrectos pasan desapercibidos. Se descubren 3 meses después.

Datos con esquema son una sociedad con estado de derecho. Rompe las reglas y eres rechazado inmediatamente. Las razones se declaran. Puedes corregir y reintentar.

De no estructurado a estructurado

La mayoría de los datos del mundo real no están estructurados: archivos Excel, grabaciones de llamadas, actas de reuniones, documentos PDF, emails.

Para que los agentes manejen estos datos, la estructuración debe ser primero.

Datos no estructurados → Decidir esquema → Transformar → DB

Excel       →  Declarar DDL   → importar → PostgreSQL
Grabaciones →  STT            → Estructurar → DB de resúmenes
Actas       →  Parsear        → Extraer acciones → DB de tareas
PDF         →  OCR + Parsear  → Extraer campos → DB de documentos

El punto clave: Los humanos deciden el esquema (estructura), los agentes ejecutan la transformación.

La “separación de decisiones e implementación” de la Clase 5 se aplica idénticamente aquí.

Patrón de validación de datos: Defensa en 3 capas

1a línea de defensa — Restricciones de DB (la más poderosa)

NOT NULL           -- Prevenir valores vacíos
UNIQUE             -- Prevenir duplicados
CHECK (amount > 0) -- Restricción de rango
FOREIGN KEY        -- Integridad referencial
DEFAULT            -- Garantizar valores por defecto

Las restricciones de DB son imposibles de evadir. Sea cual sea el código que escribas, sea cual sea el agente que uses, los datos que violan restricciones no entran. Las reglas más importantes deben declararse como restricciones de DB.

2a línea de defensa — Reglas de negocio (Rego)

Algunas reglas no se pueden expresar como restricciones de DB. “Descuentos superiores al 30% requieren aprobación del gerente”, “más de 3 pedidos al día del mismo cliente es transacción sospechosa.” Estas reglas se declaran en Rego.

# Reglas de validación de pedidos
deny[msg] {
    input.order.discount > 30
    not input.approver.role == "manager"
    msg := "Descuentos superiores al 30% requieren aprobación del gerente"
}

warn[msg] {
    count(input.customer.orders_today) >= 3
    msg := "Mismo cliente 3+ pedidos hoy — verificar transacción sospechosa"
}

Las reglas Rego son uno de los SSOTs de yongol. La validación cruzada de la Clase 4 funciona aquí también.

3a línea de defensa — Trinquete de migración

Verifica que los datos existentes sean compatibles con el nuevo esquema cuando el esquema cambia.

Mismo patrón, diferentes dominios

¿Ves el patrón común a través de las Clases 8, 9, 10?

Todos la misma estructura:

Declarar, verificar, bloquear, persistir.

“Las restricciones son contratos” de la Clase 5 atraviesa los tres dominios:

• Contrato del código: filefunc 22 reglas, yongol 287 reglas de validación cruzada
• Contrato del sistema: Docker Compose, Terraform, pipelines CI/CD
• Contrato de los datos: Restricciones DDL, reglas Rego, trinquete de migración

Cuando restricciones razonables son verificables, las violaciones están definidas y se pueden hacer cumplir — cualquier dominio converge.

DDL → sqlc → Código: Encadenamiento sin fisuras

Desde el esquema (DDL) hasta la generación de código, no hay espacio para la interpretación humana. DDL cambia → sqlc cambia → el código generado cambia → los tests lo detectan. Esta es la estructura donde el drift no ocurre en el desarrollo dirigido por datos.

La práctica de datos del vibe coder

“No sé de DB — ¿cómo lo hago?”

No necesitas saber. El agente escribe el DDL. Lo único que haces es decidir qué almacenar.

Al agente: "Crea una tabla de gestión de clientes.
- Necesito nombre, teléfono, email, fecha de registro
- El teléfono debe empezar con 010
- El email debe ser único
- La fecha de registro se llena automáticamente
Créala como DDL con restricciones."

Las decisiones en lenguaje natural. La realización de decisiones en DDL. La verificación del DDL por la máquina.

La verdad desaparece a la velocidad de la luz

Aquí extraemos una última filosofía de este curso.

La física cuenta un hecho frío. En el momento en que ocurre un evento, su verdad desaparece a la velocidad de la luz. La Luna de hace 1 segundo es la Luna de hace 1.3 segundos. Una galaxia a 10,000 millones de años luz es su apariencia de hace 10,000 millones de años.

La verdad desaparece físicamente. Lo que queda son solo afirmaciones — fragmentos de verdad.

Los datos son lo mismo. “Monto de pedido 50,000 won” en la DB no es verdad. Es una afirmación. Una afirmación que alguien puso en algún momento por algún camino. Por eso importan el origen y la marca de tiempo. Datos sin origen son afirmaciones sin evidencia. Datos sin marca de tiempo son un periódico sin fecha.

Lo que hace el esquema es dar estructura a las afirmaciones. “Esta afirmación debe tener esta forma, debe satisfacer estas restricciones, debe venir de esta fuente.” Esta estructura es la ley de los datos.

Lo que no tiene origen no es mi dato. Lo que no tiene marca de tiempo no es mi registro. Lo que no tiene esquema no es dato de mi sistema.

Visión de la Clase 10: Dilo y se construye — Código, sistema, datos

En la Clase 1 empezamos aquí.

“Crea una app de lista de tareas.”

Apareció código. Funcionó hasta 3 funcionalidades. Se derrumbó a las 5.

Al final de la Clase 10, donde estamos:

El mundo de la Clase 1:
  "Crea una app" → Aparece código → Se derrumba a 5 funcionalidades

El mundo de la Clase 10:
  "Crea un SaaS de gestión de pedidos"
  → Decisiones: Definir esquema, declarar funcionalidades, declarar reglas
  → Código: yongol genera desde SSOT (Clase 8)
  → Sistema: CI/CD automatiza compilar-desplegar-monitorear (Clase 9)
  → Datos: DDL fuerza esquema, Rego valida reglas (Clase 10)
  → Aprobación: El humano solo presiona "aprobar"
  → No se derrumba ni a 200 endpoints

Código → Sistema → Datos. El mismo principio funciona en los tres dominios.

Declarar, verificar, bloquear, persistir. Las decisiones por humanos, la implementación y verificación por máquinas. No gobierno de personas sino estado de derecho.

De “crea una app de lista de tareas” en la Clase 1 a “crea un SaaS de gestión de pedidos” en la Clase 10 — lo que cambió no es el tamaño del modelo. Es la estructura. Le pusimos riendas al agente, tendimos rieles y establecimos la ley.

Dilo y se construye. No solo código, sino sistema y datos también. Para que eso sea posible, debe haber riendas, deben haber rieles, debe haber ley. Diseñar esas riendas, esos rieles y esa ley es Reins Engineering.

Empezaste este curso sin poder leer una sola línea de código. Habiendo terminado la Clase 10, lo que cambió no es que ahora puedas leer código. Ahora sabes qué decirle a los agentes, por qué decírselo y cómo verificar sus reportes. Esta es la capacidad de quien toma decisiones.

Artículos relacionados

• Las restricciones son contratos
• Las triples no son hechos sino afirmaciones

Curso completo de Reins Engineering

Fuentes

• Stanford, “Lost in the Middle: How Language Models Use Long Contexts” (2024) — 30%+ de caída de rendimiento cuando la información relevante se entierra en medio del contexto (re-referencia de Clase 8)
• Amazon, “Context Length Alone Hurts LLM Performance” (2025) — 13.9-85% de caída de rendimiento incluso con tokens de espacio en blanco (re-referencia de Clase 8)
• E.F. Codd, “A Relational Model of Data for Large Shared Data Banks” (1970) — Modelo de base de datos relacional, fundamento teórico de la integridad de datos basada en esquemas
• OPA (Open Policy Agent) / Rego — Lenguaje de políticas declarativo para verificar reglas de negocio fuera del código
• Encadenamiento DDL → sqlc de yongol — Estructura de validación cruzada sin fisuras desde esquema hasta código con seguridad de tipos
• Principio del estado de derecho (Rule of Law) — Las tres condiciones de verificabilidad, definición de violación y capacidad de cumplimiento se aplican idénticamente a código/sistema/datos
• “La ley no es justicia (正義) sino definición (定義)” — Filosofía del estado de derecho digital, presentando el esquema como el análogo de la ley
• “La verdad desaparece a la velocidad de la luz” — Fundamento para el rastreo de origen/marca de tiempo de datos desde las limitaciones de la observación física