La escalera de verificación: cuando el dominio escribe su código

Generar código es ahora casi gratis; verificarlo, no. Esa asimetría —barato de generar, caro de verificar— era el techo de los agentes en producción, y cuando el experto de dominio —el contable, el de soporte, quien conoce las reglas— empieza a generar sus propios módulos con un asistente de IA, se vuelve el problema central del equipo: el volumen de código crece más rápido de lo que nadie puede leerlo.

La respuesta no es revisar más. Es subir una capa: dejar de competir escribiendo el código que la IA genera en segundos, y pasar a ser dueño de las invariantes del dominio —las reglas que no se pueden romper— y de los verificadores más baratos que las hacen cumplir solas. La herramienta que organiza ese trabajo es una escalera.

El código se comoditiza; las invariantes no

Las ofertas de Forward Deployed Engineer —el ingeniero que despliega producto pegado al dominio del cliente, escribiendo código que entra en producción real— pasaron de 643 en abril de 2025 a 5.330 un año después: un 729% interanual (datos de Indeed vía Business Insider). No es casualidad: el cuello de botella del software en un dominio regulado se movió de escribir el código a saber cuál es correcto.

La IA comoditiza escribir código. No comoditiza saber qué asiento es legal en contabilidad española, ni mantener un sistema vivo en producción durante años, ni —lo nuevo— poseer el conjunto de datos que mide si un agente hace bien el trabajo. El CTO de Ramp lo resume así: “your code is the LLM now… plus instructions and an infinite loop” (entrevista). El producto deja de ser solo código determinista y pasa a incluir agentes con instrucciones; un agente sin un test que lo mida es un agente que no sabes si funciona.

La acción concreta: escribe la lista de qué invariantes de tu dominio viven solo en la cabeza de quien las conoce y no en un verificador que las bloquee. Esa lista es tu backlog real.

Revisa superficies, no diffs

Revisar el 100% de los diffs que genera la IA no escala, te quema y te convierte en el departamento del “no”. El código no pesa todo lo mismo: un panel de informes roto se arregla el martes; un asiento mal generado es una declaración de impuestos mal presentada.

La frontera la marca el blast radius —el alcance del daño si algo se rompe—. Zona caliente: dinero, libro mayor, cálculo de impuestos. Zona fría: listados, informes de solo lectura, paneles internos. La zona caliente exige los verificadores estrictos; en la fría, que cualquiera (humano o agente) genere lo que quiera, porque romper es barato. Y la frontera es arquitectónica, no de proceso: el código de zona fría no escribe en las colecciones contables, y eso se comprueba en el sistema, no se confía a la buena fe.

La acción concreta: marca qué módulos tocan el libro mayor o el dinero, revisa solo las superficies de esos, y deja romper el resto sin tu ojo encima.

La escalera de verificación

Menos del 5% de los diffs deberían llegar a tus ojos; al resto lo cubre un verificador más barato. La escalera ordena esos verificadores de gratis a escaso, y el trabajo del ingeniero es empujar cada comprobación lo más abajo posible:

• N1 · Tipo o schema —el contrato de forma de los datos: importe como Decimal, fecha-calendario como tipo propio—. Gratis, en cada tecla. Lo que es imposible de representar no hay que verificarlo.
• N2 · Lint semántico de dominio —reglas que leen el árbol de sintaxis y bloquean patrones prohibidos—. Segundos, en cada PR. Caza el error antes de que exista, y el punto de integración importa: Google fijó como umbral tolerar hasta ~10% de falsos positivos en un check de code review, pero exigir ~0% en compile-time (estudio).
• N3 · Test determinista y property-based —genera miles de casos válidos y afirma una propiedad universal: para toda factura, su asiento cuadra—. Minutos, en cada PR. La técnica es vieja (QuickCheck, 2000); para salidas sin respuesta correcta que comparar, como las de un parser con IA, su prima es el metamorphic testing: afirmar una relación entre dos salidas en vez de un valor exacto.
• N4 · Check de integridad sobre datos reales —las invariantes ejecutadas contra producción cada noche por un cron—. Nocturno. Detecta el descuadre antes que el cliente; inferir y vigilar invariantes sobre ejecuciones reales es lo que hace Daikon desde 2001.
• N5 · Benchmark agéntico (pass@k) —aciertos en k intentos: el único verificador posible para lo probabilístico, como un parser con IA o un cambio de modelo—. Horas, por release.
• N6 · Juicio humano —diseño, modelado, decisiones de dominio—. Caro y escaso. Lo único no delegable.

El juicio humano es el recurso más caro del equipo, así que se reserva para lo que ningún peldaño inferior cubre. Esta es la respuesta estructural a la asimetría: la IA infla el volumen de código generado, y tu escalera decide si la verificación escala con él o te ahoga (Willison sobre el reequilibrio).

La acción concreta: coge una comprobación que hoy solo hace tu ojo (N6) y bájala un peldaño —la regla que repites en cada review se convierte en un lint (N2) que se ejecuta solo.

Todo incidente baja un peldaño

Cada fallo que detectas en un peldaño debería generar, en menos de 5 días, un verificador en un peldaño inferior que lo cace la próxima vez. Un descuadre que encontró un cliente —N6, el peldaño más caro y vergonzoso— se convierte en check nocturno (N4), test de regresión (N3) y, si toca un parser, tarea del benchmark (N5).

Es un mecanismo de interés compuesto. Cada incidente deja el sistema más barato de operar, no más caro, y al cabo de un año la plataforma sabe más del dominio que cualquier persona individual. La clave es asentar el aprendizaje dos veces: en forma humana —una nota, una decisión registrada— y en forma ejecutable —el check—. Asentado solo en una cabeza, se va con la persona; asentado solo como check, nadie recuerda por qué existe y acaba borrado.

Ramp lo midió y encontró lo que nadie intuye: la mayoría de sus skills restaban rendimiento al agente, y a una se le podía recortar el contexto un 64% sin apenas mover la puntuación —la prueba de que casi todo ese contexto era ruido (benchmarking de su agente contable). Sin el peldaño que mide, cada una de esas decisiones se toma a ciegas.

La acción concreta: coge el último incidente que te reportó un cliente —no tú— y escribe el verificador más barato que lo habría frenado. Que baje de tu ojo a una máquina.

Nada de esto es nuevo: el linaje de la escalera

Las fitness functions —el género que convierte en un check de CI cualquier propiedad de la arquitectura— se nombraron en 2017 (Building Evolutionary Architectures, de Ford, Parsons y Kua), pero la escalera fusiona tres tradiciones bastante más viejas.

La pirámide de tests, estirada por los dos extremos. Mike Cohn la dibujó —muchos tests baratos abajo, pocos caros arriba— y Martin Fowler la fijó; Kent C. Dodds la rotó a testing trophy añadiendo el análisis estático como base y razonando por retorno confianza/coste. La escalera la estira más: hacia abajo, hasta el tipo que hace el estado ilegal irrepresentable —“parse, don’t validate” de Alexis King, las invariantes del Design by Contract de Bertrand Meyer (1992)—; y hacia arriba, hasta el invariante vigilado en producción y el benchmark agéntico, que la pirámide clásica no tenía. La raíz del principio “barato y temprano” es el shift-left de 2001.

Los métodos formales, en versión ligera. No hace falta demostrar el código: AWS especifica el diseño en TLA+ para cazar bugs de concurrencia que ningún test instancia —“prevent serious but subtle bugs from reaching production”—. El tipo (N1) es la versión más barata de esa misma idea: una prueba que el compilador comprueba gratis —en un libro mayor de doble entrada, el tipo que hace que un asiento descuadrado ni siquiera llegue a compilar.

El poka-yoke de Toyota, para la regla 3. “Todo incidente baja un peldaño” no nació en el software: es jidoka —parar la línea ante el primer defecto y arreglar la causa, no el síntoma— y poka-yoke —diseñar el proceso para que el error no pueda repetirse—, de la fábrica de Toyota de los años 60. El postmortem sin culpa de Google SRE y el “test de regresión por cada bug” de Fowler son la misma jugada: convertir el fallo en una guarda permanente y barata. Y “asentar el conocimiento dos veces” también tiene nombre —specification by example (Gojko Adzic) y living documentation (Cyrille Martraire)—: el ejemplo que es a la vez prosa para el humano y test para la máquina.

Revisa tu escalera y ponle a cada peldaño el nombre de su ancestro: el que no tenga ninguno probablemente no es un peldaño, es una costumbre sin verificar.

Para profundizar

El tipo como prueba (N1):

• Parse, don’t validate — Alexis King, 2019. La validación tira lo que aprendió; parsear lo fija en el tipo. Post
• Applying “Design by Contract” — Bertrand Meyer, IEEE Computer, 1992. Precondición, postcondición e invariante de clase como código. PDF
• Designing with types: making illegal states unrepresentable — Scott Wlaschin, 2013. Reglas de negocio como compile-time unit tests. Post

La estrategia de verificación:

• Building Evolutionary Architectures — Ford, Parsons, Kua, 2017. El origen de las fitness functions (libro, O’Reilly).
• TestPyramid — Martin Fowler, 2012. Bliki
• The Testing Trophy — Kent C. Dodds, 2017. Añade el análisis estático como base de la pirámide. Post
• Lessons from Building Static Analysis Tools at Google — Sadowski et al., CACM 2018. Por qué el check tiene que llegar en el flujo del developer. PDF

Propiedades y métodos formales:

• QuickCheck — Claessen y Hughes, ICFP 2000. El paper fundacional del property-based testing (ACM Digital Library).
• How Amazon Web Services Uses Formal Methods — Newcombe et al., CACM 2015. TLA+ para verificar el diseño, no el código. PDF
• Dynamically Discovering Likely Program Invariants (Daikon) — Ernst et al., IEEE TSE 2001. Inferir invariantes de ejecuciones reales. Resumen

Conocimiento ejecutable e incidentes:

• Specification by Example — Gojko Adzic, 2011. El ejemplo que es spec, test y documentación viva a la vez (libro).
• Documenting Architecture Decisions — Michael Nygard, 2011. El ADR: registrar el porqué, no solo el qué. Post
• Postmortem Culture: Learning from Failure — Google SRE, 2016. El postmortem sin culpa. Capítulo
• Poka-yoke — Shigeo Shingo, Toyota Production System. Diseñar el proceso para que el error sea imposible. Referencia

El código que escribas hoy probablemente lo reescriba un modelo mejor en seis meses. La escalera que construyas alrededor —los peldaños baratos que verifican tu dominio— se queda y se ejecuta sola. No es defenderte de la IA: es ser la persona gracias a la cual la IA de todos los demás funciona en producción.

¿Cuántas de las reglas que repites en cada review siguen viviendo solo en tu cabeza, y no en un peldaño que las compruebe por ti?