Todos los fallos de migración que hemos visto en otro software vienen del mismo sitio: tratar “primero limpia los datos” como problema del cliente en vez de como problema del producto. No queríamos construir eso. Así que, al principio, nos topamos con un caso real, y nos enseñó algo que no esperábamos: a veces la respuesta correcta a “¿debería encargarse la IA de esto?” es no.
La migración que nos enseñó la diferencia
Teníamos una exportación real de un CRM heredado que traer: 349 empresas, 491 notas, la mayoría historial de llamadas escrito en esloveno, 393 contactos. El movimiento obvio habría sido pasarlo por Neo, nuestra importación asistida por IA, la misma que lee una hoja de cálculo desordenada y propone registros limpios a partir de ella.
Decidimos que no. Los datos de origen ya estaban estructurados, ya resueltos, ya eran correctos. Pasarlos por una pasada de IA no habría añadido nada salvo riesgo: un modelo parafraseando o resumiendo notas de llamadas reales en esloveno, perdiendo precisión en silencio en un texto que necesitaba quedar exactamente como estaba escrito. Así que construimos un segundo camino, separado, deliberadamente sin IA: copiado exacto y determinista, emparejado por ID de registro heredado, conservando las marcas de tiempo originales, sin ningún modelo de lenguaje en ninguna parte.
Construir ese camino sacó a la luz brechas reales que de otro modo no habríamos encontrado: un campo de formulario que el backend había estado descartando en silencio quién sabe desde cuándo porque la columna de base de datos detrás de él nunca había existido, contactos que se venían embutiendo en notas de texto libre por no tener un sitio propio donde vivir. Arreglamos ambas cosas para siempre, no solo para esta migración.
Esa es la forma real del Migration Engine ahora: Neo para el desorden honesto, tíranos vuestra peor hoja de cálculo y os diremos con claridad qué pudimos entender y qué no, y un camino de copia exacta y silencioso para los datos que ya son confiables y solo necesitan llegar intactos. Dos problemas distintos. Dejamos de fingir que eran uno solo.
Llegar a algo que valga la pena probar, siquiera
Nada de lo que se prueba abajo importa si no hay nada real debajo. Sinceramente, parte de cómo llegamos aquí empezó por accidente. Las grabaciones de pantalla se seguían posponiendo, sobre todo por pura reticencia a sentarse a grabar algo como es debido, así que la solución real fue simplemente ver a la IA hacer clic por la app en vivo y tomar notas de lo que pasaba. Eso resultó ser uno de los mejores métodos de depuración que encontramos en todo el proyecto, no un plan inteligente, sino un subproducto de no querer hacer otra cosa. Unas cuantas funciones reales existen hoy porque un bug se detectó exactamente así.
La construcción más grande siguió una forma parecida, menos por gran diseño que por necesidad: una pieza real cada vez, cada una probada de principio a fin antes de empezar la siguiente, porque un proyecto de este tamaño no se mantiene cuerdo de ninguna otra manera. Lo que de verdad nos sorprendió es que la suite de pruebas base acabó prediciendo cosas que nadie le había pedido predecir. Añades una función nueva meses después, y Velvet a veces detectaba que alguna pieza adyacente llevaba todo ese tiempo a medio terminar, en silencio, esperando a que alguien se diera cuenta. No porque nadie implicado sea especialmente agudo. Una prueba que de verdad hace clic en el botón y comprueba el resultado real tiene su manera de encontrar cosas que una persona ojeando el código no encontraría.
Velvet
En algún punto del camino, nuestra propia suite de pruebas end-to-end recibió un nombre en vez de quedarse en “las pruebas”. La llamamos Velvet. Unas cinco mil líneas de Playwright, repartidas en doce suites con nombre, smoke, regresión, el Vault, el AI Village, flujos de action-bus, casos límite duros, estrés, entre otras, ejecutadas contra cinco empresas sintéticas y pobladas separadas. Maneja la aplicación real, en funcionamiento, backend y frontend ambos en vivo, sin sustituto simulado para ninguno de los dos.
Dentro de las suites de regresión con nombre, las llamadas a la IA están simuladas con respuestas deterministas, a propósito, no como atajo. A volumen real, las llamadas genuinas a la IA chocan con los límites de conexión del navegador y producen fallos que no tienen nada que ver con si el producto realmente funciona. Simularlas ahí aísla una pregunta honesta, funciona la fontanería, de otra, es buena la respuesta real de la IA, que se prueba por separado, de verdad.
La disciplina bajo cada capa
Cinco reglas se aplican en todo lugar donde se prueba en este proyecto, no solo en Velvet:
Dejar por escrito una predicción antes de correr la prueba, para que un resultado exitoso no pueda redefinirse en silencio después como lo que resultó pasar. Una prueba que solo confirma que un botón existe no es una prueba; tiene que hacer clic en el botón, esperar la respuesta real, incluida la latencia real de la IA, y comprobar el estado resultante real. Cada función se prueba haciendo lo que se supone que debe hacer, y se prueba de la forma en que una persona real, a veces descuidada, a veces adversarial, la usaría mal de verdad. Cuando un “fallo” resulta ser un bug en el script de la prueba y no en el producto, eso también se reporta, no se parchea en silencio y se olvida. Y un arreglo no está terminado cuando el código compila; está terminado cuando el escenario exacto que se rompió se ha vuelto a ejecutar de verdad y ha pasado.
Más allá de Velvet: siete capas, no una
Velvet es una capa de siete. La verificación real de IA, sin simular, se ejecuta por separado, un script puntual contra la app en vivo con llamadas genuinas al modelo, limpiado después, específicamente para atrapar la clase de bug que solo aparece porque la respuesta de un modelo real varía de una ejecución a otra. La simulación de horizonte largo ejecuta historias empresariales simuladas, un mes, un año, cinco años, contra inquilinos reales con llamadas a la IA en vivo durante todo el proceso, haciendo las mismas preguntas canónicas en varios puntos para comprobar si las respuestas realmente se volvían más precisas a medida que se acumulaba la historia, no solo si volvían siquiera. Una capa adversarial deliberada, ocho pruebas hostiles que llamamos el Obstacle Course, intenta romper directamente las afirmaciones de honestidad y seguridad del producto: inyección de prompts, fuga de datos entre inquilinos, instrucciones contradictorias, resistencia al borrado, conciliación financiera real, manejo de cuentas duplicadas. Las pruebas unitarias e de integración de backend cubren la Sacred Spine y la ingesta de documentos de principio a fin. Los recorridos guiados prueban la interfaz real en tamaños de pantalla reales, escritorio y un viewport móvil genuino, con capturas de pantalla como prueba, no una simple casilla marcada. Incluso los vídeos de presentación sirvieron como capa de prueba: cada uno es un guion real ejecutándose contra la app real y en vivo, y cada momento que se veía ligeramente raro durante la revisión se rastreó individualmente hasta un bug real o un problema de sincronización del guion, nunca se asumió que era uno u otro sin comprobarlo.
En todo el conjunto, unos veinticinco años simulados de actividad empresarial, varios sectores, más de nueve mil entradas reales de Vault generadas en el camino, once bugs reales encontrados y corregidos. Gasto real total en API para todo el programa: 9,57 dólares.
Lo que no vamos a afirmar
No hemos probado la escala empresarial, miles de inquilinos concurrentes a la vez. No hemos probado bajo carga lo que pasa con el coste de la IA en un chat diario genuinamente intensivo y abierto, a diferencia de la actividad empresarial guionizada en torno a la que se construyó la mayor parte de estas pruebas. Durante el trabajo descrito arriba, encontramos un riesgo real de escalabilidad en nuestro propio relleno retroactivo de embeddings, la puesta al día de una sola vez de un Vault grande acercándose incómodamente a un tiempo de espera de solicitud, y os lo contamos en vez de parchearlo en silencio y no decir nada.
Nada de esto es perfecto, porque nada lo es. Lo que sí podemos respaldar de verdad es que revisamos, a fondo, nuestras propias afirmaciones antes de presentároslas, y que os contamos lo que encontramos en ambos sentidos. Esa es toda la disciplina. Vamos a seguir haciéndolo.