DATAMIMIC: datos sintéticos deterministas para coding agents

Por qué los coding agents rompen tus tests

Los agentes de código que escriben su propia suite de pruebas suelen tomar un atajo: inventan datos de prueba "lo suficientemente parecidos" a producción — un paciente de 25 años con Alzheimer, una transferencia con fecha futura, un usuario sin país. Funcionan para una demo. Se rompen al primer commit serio.

DATAMIMIC, proyecto open-source de la alemana rapiddweller, ataca exactamente ese hueco: darle al agente un motor que genera datos deterministas, con conciencia de dominio, y compatibles con flujos regulados. La edición Community (CE) es MIT y 100% Python; la Enterprise (EE) añade gobernanza, escaneo PII y ejecución multi-sistema.

Qué hace distinto a DATAMIMIC de un Faker cualquiera

Las bibliotecas aleatorias tradicionales (Faker y similares) producen datos azarosos e incoherentes entre sí: si pides una edad y una condición médica por separado, nada garantiza que tengan sentido. Como resume el propio README del repositorio, una llamada típica a Faker() puede devolver "un paciente de 25 años con Alzheimer" — absurdo clínico que pasa toda validación sintáctica y bloquea cualquier test real.

DATAMIMIC resuelve ese problema con tres contratos:

• Determinismo byte-a-byte: misma versión del motor + mismo modelo + misma semilla = salida idéntica en cualquier máquina. Lo verifican gates de CI en cada release (tests_ce/architecture/).
• Relaciones entre dominios: edad, condición clínica, IBAN y país se generan de forma coherente dentro del mismo modelo — un paciente geriátrico no carga una tarjeta de débito juvenil.
• Proveniencia por salida: cada lote lleva un determinism_proof.content_hash que permite re-ejecutar y verificar los datos meses después. Crítico para auditoría regulatoria y para re-ejecución de tests de agentes.

El generador trabaja con conectores a PostgreSQL, MySQL, Oracle, MS SQL, SQLite, MongoDB, CSV, JSON, XML, XLSX y DbUnit, y exporta también formatos anchos fijos (.fcw).

Cómo encaja con agentes IA y MCP

El repo incluye un AGENTS.md y un adaptador MCP instalable con pip install "datamimic-ce[mcp]". El contrato entre un agente y el motor es deliberadamente mínimo:

• reference → consulta qué generadores existen para un dominio (persona, paciente, cuenta bancaria, etc.).
• scaffold → crea un model.dm.json con la intención declarada, lo compila, lo lint-ea y hace un dry-run acotado. Si falla, devuelve path / code / message / allowed_fields para que el agente repare sin inventar campos.
• check y run (bounded) → re-ejecuta una verificación sobre el descriptor generado.

La idea: en lugar de pedirle al agente que escriba fixtures a mano (donde tiende a alucinar nombres de campos, tipos y relaciones), le das un andamiaje que falla rápido con diagnósticos estructurados. La regla de oro del repo lo dice textual: "never invent your own test world — use the canonical scaffold transaction".

Esto importa especialmente para founders hispanohablantes que construyen productos verticales (healthtech, fintech, edtech). Cuando tu agente genera endpoint /patients/123 automáticamente, necesitas que el Patient inyectado respete la lógica de dominio del cliente, no un JSON random que valide Swagger pero rompa en el siguiente sprint.

Pseudonimización: el lado regulatorio

DATAMIMIC CE soporta dos modos de pseudonimización sobre staging/QA, ambos con clasificación GDPR explícita en su documentación:

• Seeded (con rngSeed): determinista, reproducible — se clasifica como pseudonimización según GDPR Art. 4(5).
• Non-seeded (sin seed): no determinista, sin mapeo reversible — postura de privacidad máxima para entregas únicas.

La edición CE exige mapear los campos PII a mano en el XML. La versión Enterprise automatiza ese paso con un escáner probabilístico configurable desde el módulo DataWorkbench. Para equipos en sectores regulados — banca europea donde el repo dice tener despliegues, salud, seguros — el camino es: empezar con CE para prototipos, migrar a EE cuando los auditores pidan proveniencia por ejecución.

Qué significa esto para tu startup

Si tu producto usa agentes IA para generar código o tests, el talón de Aquiles rara vez es el LLM: es la calidad y coherencia de los datos que usa para verificar. Un mock correcto por debajo se traduce en menos regresiones silenciosas, mejores demos a inversores y onboarding más rápido para clientes enterprise que auditan pipelines.

Acciones concretas que puedes aplicar esta semana:

• Audita tu último bug post-deploy: si venía de un fixture generado al azar, evalúa migrar a un motor determinista con seed fija. El coste de cambio es bajo — DATAMIMIC CE se instala con pip install datamimic-ce y corre en CI sin servidor extra.
• Inyecta DATAMIMIC en el loop de tu agente: añade el adaptador MCP a tu coding agent (Cursor, Claude Code o tu propio orquestador) y reemplaza los mock(uuid4()) por scaffold(model.dm.json, seed="ci-2026"). Cada PR será reproducible para QA.
• Si vendes a banca o salud en LATAM/España: modela la postura regulatoria desde el día uno. Separa staging (seeded, reproducible) de delivery one-shot (non-seeded, máxima privacidad) y documenta la diferencia en tu RFP.

Fuentes

• rapiddweller/datamimic — repositorio oficial (Community Edition MIT)
• TechTarget — Guide to synthetic test data

---

Nota editorial: el artículo cubre la versión CE 4.x disponible en el repositorio público. El comparativo frente a herramientas comerciales y el detalle de la edición Enterprise se basan en las tablas del propio README; cifras de mercado independientes no se encontraron en fuentes verificables para esta nota, por lo que se omiten para no introducir datos sin respaldo.