Remote Frog

La semana pasada, un compañero detectó en una revisión de código cuatro anotaciones @Unique que había añadido incorrectamente a tablas de producción — anotaciones que estaban mal porque los datos tenían -algunos miles- duplicados. La revisión tenía razón. Pero la historia más interesante es cómo llegaron ahí: usé un agente que tenía una regla explícita para verificar la unicidad haciendo consultas SQL obligatorias antes de añadir cualquier @Unique. El agente no la siguió. Yo tampoco me di cuenta. Y cuando intenté entender qué había pasado, encontré problemas reales en los datos que ninguno de los dos detectó porque ambos razonábamos desde suposiciones en lugar de verificar.

Dos cosas QUE fallaron

El agente ignoró su propia regla de verificación y yo me salté los tests de transformación.

Me salté los tests que debía ejecutar o como me convertí a mi mismo en un adorno

Confié en el trabajo del agente y en que ejecutaría las reglas que le había marcado como ‘mandatory’. Y asumí erróneamente que, como el PR solo tocaba el archivo de esquema — sin SQL, sin lógica de transformación — no necesitaba ejecutar tests de transformación. Estaba equivocado. Encima, los tests de transformación habrían detectado los errores inmediatamente :epic-facepalm:

La ironía: el agente ignoró su propia regla de verificación

El agente tenía una regla de verificación explícita en su definición de skill: antes de añadir @Unique, ejecutar una consulta SQL y confirmar que duplicados = 0. Si duplicados > 0, no añadir @Unique.

### Verificación
**Antes de añadir @Unique, verificar con SQL**:
```sql
-- Comprobar duplicados (debe devolver 0)
SELECT COUNT(*) - COUNT(DISTINCT id) as duplicate_count 
FROM schema_name.table_name
-- Para clave compuesta
SELECT COUNT(*) - COUNT(DISTINCT field1, field2) as duplicate_count 
FROM schema_name.table_name
```
**Reglas**:
- `duplicate_count = 0` → Seguro añadir @Unique
- `duplicate_count > 0` → NO añadir @Unique (investigar por qué)

No ejecutó la consulta. En su lugar, infirió la unicidad a partir de los nombres de los campos y de la lógica del esquema — un atajo que parecía razonable (??). Pero estaba completamente equivocado.

El caso es que le pedí al agente que me explicara por qué se había saltado una orden explícita y directa. Me dijo que la regla estaba “enterrada en la línea 144 de un documento largo”. Vale. Una respuesta conveniente, pero falaz — el documento tenía unas 400 líneas con progressive disclosure, bastante asequible para un agente. Y entonces, ¿qué pasó? Pues nunca se sabrá. Lo más probable: el agente encontró un camino localmente coherente hacia la respuesta y se saltó el paso de verificación porque nada le obliga en realidad a detenerse. Y esto nos lleva de nuevo al tema del no determinismo de los modelos, pero por la vía dura. La del palo en las costillas.

Cómo actualicé el skill para hacer la verificación ‘insaltable‘

El problema fue que nada obligaba al agente a detenerse y ejecutarla (dicho por el propio agente). Así que los cambios que realicé en las instrucciones se centraron en hacer que el paso de verificación fuera imposible — o muy difícil — de sortear.

Por ejemplo, añadí un checkpoint obligatorio al principio del skill, antes de que comience cualquier trabajo de anotación:

🚨 CHECKPOINTS DE VERIFICACIÓN OBLIGATORIOS 🚨
- @Unique: DEBES verificar con consulta SQL antes de añadir (comprobar duplicados = 0)
- @ForeignKey: DEBES verificar con consulta SQL antes de añadir (comprobar huérfanos = 0)
- Si te saltas la verificación, AÑADIRÁS anotaciones incorrectas

Además del checkpoint, añadí un requisito de evidencia de verificación: el agente debe registrar el resultado de la consulta SQL en su respuesta antes de proceder, en un formato estructurado:

Tabla: schema.nombre_tabla
Columna(s): nombre_campo
Consulta: SELECT COUNT(*) - COUNT(DISTINCT nombre_campo) FROM schema.nombre_tabla
Resultado: 0 duplicados ✅ (o X duplicados ❌)
Decisión: Añadir @Unique / NO añadir @Unique

Esto importa porque hace visible el razonamiento. Si el agente se salta la consulta, la ausencia del output es inmediatamente obvia en el resultado. O debe de serlo.

También añadí un pre-flight check que verifica que el entorno de base de datos está conectado antes de empezar. Sin él, las consultas SQL no pueden ejecutarse y el agente podría tener la tentación de saltarse a la chita callando la verificación en lugar de bloquearse. El skill ahora pide al agente que se detenga e informe si esto ocurre.

Finalmente, añadí un script de validación automatizado que puede ejecutarse al final para confirmar que todas las anotaciones @Unique en el archivo están respaldadas por una unicidad real en los datos de producción.

El resultado: la definición del skill es ahora un 25% más larga. Y la verdad incómoda es que he elevado el coste de saltarse la verificación, eso seguro, pero no estoy 100% seguro de que siempre funcione. Por ejemplo, el script de validación en Python es determinista en el sentido correcto: dados los mismos datos, siempre devuelve el mismo resultado. Pero si el agente realmente lo ejecuta o no, eso no es determinista en absoluto. Esa es la tensión no resuelta con la que tenemos que trabajar.

La lección.

Tres cosas fallaron simultáneamente: me salté un test que debería haber ejecutado, el agente se saltó un paso de verificación que se le dijo explícitamente que ejecutara, y los datos tenían problemas reales que ninguno de los dos detectó porque ambos razonábamos desde suposiciones en lugar de verificar.

Las mejoras en el skill ayudan. Hacer la verificación explícita, estructurada y que produzca evidencia eleva el coste de saltársela -y el coste humano de no validar el trabajo del agente-. Pero la lección interesante no es añadir más reglas a la definición del skill — sino reconocer que cuando algo aparece como evidentemente correcto, es exactamente el momento de verificarlo.

En el lado positivo: la revisión del PR no solo detectó cuatro anotaciones incorrectas — llevó a correcciones reales en las tablas subyacentes y las transformaciones que las alimentan. El pipeline está más limpio ahora de lo que estaba antes del error. Un final feliz.